App ideas are everywhere. Everyone seems to have an an idea for ‘the next big thing’. Or even if they don’t dream as grandly as imagining themselves creating the next Facebook/Uber/Snapchat, they still believe they can easily make the transition from wafty-idea-floating-around-inside-their-head to a profitable online business. All they need is someone with some engineering skills.

If you work in tech, engineering, or IT as it was formerly (and very boringly) known, you have probably been on the receiving end of many of these conversations. I know that I have, especially so in the early days of the App Store when I managed to make a few thousand dollars from a card game and a beer calculator.

Everyone, even strangers I had just met, used to tell me about their ‘brilliant idea’. Then the conversation would go a bit like this...Business plan? No. Market testing? Don’t need it! Seed money? What’s that?

Luckily, most of these people never built their ideas. They obviously didn't find a ~~sucker~~ friend willing to blindly follow their vision and they obviously lacked the requisite skills. I didn't realise it at the time but this was one of my first observations of the interesting, and often dysfunctional, relationship between product and engineering.

Product and Engineering

First, let's clarify some things. When I refer to the product team I am talking about the design team, the product owners, researchers, marketers, and anyone in between. These are the teams who take responsibility for assessing the marketplace and determining features and products that will satisfy the users' needs.

When I say engineering I mean the team that actually builds these product ideas. They might be called the technology team, programmers, developers or engineers. It doesn't matter. I prefer engineers.

The key to success of any product, or company, is how these two teams - product and engineering - work together.

Often the product and engineering teams are separated on the org chart. On the surface this seems to make sense just as much as separating other functions like HR or Finance does. The day-to-day work between the teams is vastly different and they can have completely opposing skills, processes, and workflows.

But I’m not one to worry much about org charts. I care about how the actual work gets done and the real problem is when the somewhat logical separation of functions on paper creates real life tension in person.

Because no matter how you draw those little boxes the product and engineering teams are inextricably linked by the software they are building TOGETHER. That's right, together. No matter which camp you sit in the software is not yours, it's ours.

Put another way, the product and engineering teams are united by a single common objective; build appropriate and effective software.

The product team often tackles this problem by focusing on research, user experience flows, prototypes, and beautiful designs. The engineering team comes from a systems mindset by looking at the various technology and implementation concerns.

Both are mandatory. Neither exists in a silo. These two areas go hand-in-hand if you want to successfully build good software.

In other words, product and engineering need to work together (durrrr)

How Product and Engineering Work Together

For the past 10+ years I've seen a wide range of projects, products, teams, and companies and every one of them worked differently. In fact even at my current employer, Console Group, I've directly experienced multiple methods and structures for building software.

Here are some of the methods I've seen in progress, organised into two broad categories - the "Throw it over the fence" model and the "One team" model. It doesn't take a genius to guess which is best but let's work through them.

"Throw it over the fence"

This is surprisingly more common than you would think.

The ideal world in this scenario is that the product team does ALL their work in great detail up front, taking a concept from ideation all the way to finished detailed designs that are ready for the engineering team to pick up and build. In a truly utopian world the product team, or some stakeholder from 'the business' (oh how I hate that phrase but I’ll save that for another time) also turns up at the end of the development to check it all out, sign off that everything is wonderful, and maybe even kick off some post-development work such as marketing.

At this point everyone dances around the maypole and celebrates their success.

This utopian view looks a bit like this:

And while that does look suspiciously like the waterfall methodology it can, and frequently is, employed in Agile environments by repeating this at feature-level scale. Just imagine a bunch of these stacked on top of each on in a watefall-y way :)

Why do people like this model? Because, on the surface, it seems like the most efficient and cost effective. Both teams only touch the work once, everyone gets their work right the first time, and we get to market quickly.

And, like all good utopian ideals, it's pure fiction. What we actually get is more like one of these...

Reality 1: "Volleyball"

This is where the two teams play a game of back-and-forth over who needs to do work. The product team finishes their design and give it to the technology team, who start work. But then they hit a snag and something is not catered for. They throw it back to the product team to fix before they move on. This repeats ad-nauseum.

A subtext to this problem is what does the technology team do when they volleyball something back to product? Traditionally they have just geared up ready to build this software and now there is nothing to do. Good teams will just pick up the next piece of work but what this often means is that when product come back with their updates the technology team isn't ready any more. What was initially supposed to be only a few weeks of work end-to-end will now drag out over months.

Reality 2: "Call us when you need help”

This is slightly better than the previous method in that at least the people involved start communicating and working in parallel. And luckily for most people who try to implement the "Throw it over the fence" utopia they end up here rather than playing volleyball.

Here's how it generally pans out; The product team still does the initial upfront legwork and throw it over the fence but with the caveat of being available to help out if anything arises. As the inevitables questions and issues do arise the technology team doesn't just throw it back over the fence but instead the bring in the product team so they can work together to get things right.

The downside to this method is you end up with some double-handling and inefficiencies in the process and the team ends up taking longer than deliver than expected. It may look like this:

Reality 3: "Throw it over the fence and run away!"

I have seen this in action with big departmental-driven workplaces. Think governments and big corporations.

Basically the people, or team, responsible for the initial work on the project are no longer available. They've moved on to new projects or jobs, or they're not budgeted to do more work, or they just didn't care to begin with. The result is that the technology team is left struggling to try to figure out a way forward without guidance. And unless the initial design was perfect (hint: it NEVER is) this project is doomed.

The problems manifest as a project that drags on and on way past the deadline, a team where engagement (and thus productivity) progressively diminishes, or another half-finished project that gets put on the shelf and left to gather dust.

This is NOT a valid choice, just more of an illustration of how bad things can go. As such I am not going to draw how this plays out. Just picture a never-ended but always-dwindling involvement for engineering.

All these variations of throwing the work over the fence have something in common. They are dysfunctional and they suck. Which is why I prefer the “one team” model

Solution: One team, not two

Despite the wanky name that sounds like a slogan from a big corp recruiting drive, this is the preferred method for product and technology teams working together. This is where they act as a single team, regardless of what the lines are on an org chart.

Because that’s what we are right? One team?

The product team still starts the work on their own but the key difference is they engage with the engineering team much earlier. This has many benefits but the main ones are that it gives the product team earlier technology feedback and it gives the engineering team earlier exposure to upcoming work.

Both of these items will reduce the need for robust discussion and rework later on. It looks like this:

Measuring Success

It sounds obvious when I say that the one team method is the best. It really is. It minimises down-time and rework and delivers higher quality software in a shorter time. But the downside is you’ve theoreticaly increased the workload of the teams.

The main reason people opt for throwing it over the fence is that it looks to be the cheapest and most efficient. But the key to remember is this model only works in theory. The reality is always a bigger cost and a longer time to deliver.

Here is how these delivery methods look lined up on the same time-scale:

Obviously nothing is faster than the throw it over the fence cycle. But if we’re talking fantasy why don’t you just use a time machine to go back and deliver your software before you start building it? Then present-you can sit on a beach and drink pina coladas while future-you saves your arse. Wait, I don’t think I thought this through.

Of the possible realities, the one team model is the best choice for shipping things as fast as possible.

But time is only one factor. Cost is often even more of a driver for decisions so let’s use these examples to graph the rough cost of software development for each method:

Well would you look at that. The one team model is also (just) cheaper than the other options. That is obviously ignoring the possibility of a successful throw it over the fence methodology which I previously established as fantasy.

Summary

I am not saying anything new or groundbreaking here. This is pretty much why the waterfall method is so widely lambasted while the agile method is (or was?) so highly celebrated. But at least now I’m writing from real-life observation.

I’ve seen plenty of permutations of the throw it over the fence model and they all had big problems. But now, in my job at Console, I’m seeing the fruits of a well structured “one team” approach. We’ve gone from playing project volleyball to organising into vertical project teams that are responsible for end-to-end delivery. And it’s working well. There is always room for improvement but the difference is profound.

The takeaway here is to build your product and engineering teams in a “one team” model.

What this means is making the product and engineering teams function as one team, regardless of the organisational reporting lines. How you do that depends on your organisation but the key is to ensure they have the right environment that encourages them to act as one team, united in their goal of building usable software.

“Early, clear, and ongoing communication must be an inherent, rather than implied, part of the daily work.”

It takes some effort to get there but it is worth it. In the long run you will ship faster and at lower cost.

How do your product and engineering teams work together?