How To Put a Product Team Together

Joe Procopio
Jun 27 · 7 min read

There is no better professional achievement than launching a product and watching it succeed. But a successful product launch is really nothing more than a glorified proof of concept. No company ever survived on the hype of a launch, no matter how high the trajectory of the rocket.

Once that rocket is up in the air, we lose a lot of control over it, and the period immediately following the launch is often marked by total chaos. What we need is something that looks more like organized chaos, and for that, we need a product team.

Product, as a role, is a relatively new science pioneered by growth-stage startups and innovation-focused corporations. Traditionally labeled “product management,” Product used to be this weird mesh of marketing and release management, but now it’s a weirder mesh of engineering, technology, data analysis, and market fit.

Creating a product team haphazardly or reactively can actually amplify the post-launch chaos and create a lot of unnecessary hoops for the rest of the org to jump through. Let me tell you, the only thing worse than chaos is buzzwordy documentation of the chaos.

Like I said, this is a new science. Despite what a lot of experts will tell you, we need to build our product team the same way we build our product. Start with the core function, release, test, then fill in the gaps. You should actually build your own unique product team your own unique way.

Last week I sat down with a co-founder and COO of a young company doing data-plus-machine-learning implementations. Having passed $1 million in annual recurring revenue, and seeing some positive results frame-working their services, “Sheila” was now looking to productize their offering. She knew she needed a product team and she was looking for validation and any new ideas for building one. Here’s what we went through.

Product is one of those functions where you need a more experienced hire first, like executive or operations. In technology, you might be able to get away with a few junior developers knocking out code before you hire the CTO. In finance, a solid junior accountant can handle things for a while until you hire a CFO. Don’t do this with product.

We’ll want to hire the CPO or at least a head of product engineering first. This person is tasked with a top-down view of our product, our company, our market, and our industry, as well as trends and innovations encroaching on our domain.

While our product team needs experience ranging from tech to marketing, the first hire should lean towards tech — whatever that means for our company.

The first goal of this hire is to take the product growth responsibilities off of the rest of leadership. The CEO needs to make decisions about the future of the organization, the COO needs to keep the org running smoothly, the CTO needs to wrangle the technology. While they’ll all have input into Product, our product team should have authority over product decisions.

Shiela is in fact going to transition from COO to CPO in a parallel move with her company going all in on the transition from service to product. Smart move. Her org can survive without a COO through the transition.

Please don’t confuse product management with project management. No product company ever started the tale of their success story with “Well, we always delivered on time.”

I’ll get some heat for that, but that’s OK.

We don’t want people in charge of our product who are experts in a program. We want people in charge of our product who are experts in our product. Much more important than making sure our release schedule aligns with our roadmap, our product team needs to understand how our product fits into the market and how we can make that a better fit.

This means taking parts of Agile, or any methodology for that matter, and making it our own. This also means being wary of the addition of recurring meetings, daily or weekly updates, conference calls, Gantt charts, wikis, user stories, retros, stand-ups, scrums, or heavy reliance on any metric that can’t be directly tied back to revenue.

I’m not saying ban these things, I’m just saying adopt them when it becomes painful to live without them, and not a minute before. Stick with core function, release, test, fill the gaps.

Let’s use a product roadmap as an example. Start with a list of new features prioritized by their expected increase in margin. Then break those features out into manageable two-to-four week chunks, call those releases, throw them on a timeline. When this becomes too bulky to manage in a document, go to Trello or something like it.

There you go. That’s Agile. Ish.

The primary focus of our product team should be on the product out, not the customer in. The reason is that if we’re constantly measuring the success of our product by how many customers we have and where we’re finding them, it’s like reaching into a sock drawer in a dark room and hoping we pull out a matching pair. Then leaving the room to check the results. Then going back into the room to try again.

Let’s organize that sock drawer first.

The first relationship the product team needs to establish is with the product, not the customer. We need to know how our product performs, in strict terms of revenue and margin, where the problems start, and where performance breaks down into losses. We need to know all of the major use cases, most of the minor ones, and how the customer gets onboarded into the cycle of a use case.

Once we figure out the means and the metrics, we need to integrate a measurement function into the product itself if it’s not already there. In other words, if there’s a button our customers push that’s very valuable to our bottom line, we need to know why they pushed it, and if they looked at it and didn’t push it, we need to know why they did that too.

Then, when these data collection mechanisms are in place and the analysis of that data is reported in real time, we’ve got a solid handle on our product and we can then focus on on the customer in. Now our product team can start experimenting with accommodating the customer that’s one degree away from our best customer, with the goal of serving them in the same, satisfying manner, thereby increasing our army of best customers.

Our product team shouldn’t be grouped together, they should be integrated throughout the company.

The following folks may or may not report up to the CPO or head of product, it all depends on the structure of the company.

Implementations: This is where the product meets the customer, especially for B2B. In B2C or smaller revenue products, this is usually where you find Customer Success, Onboarding, Training, or other functions designed to, as described above, get a new customer to become one of our best customers.

Services: If there is any service element with our offering, Services exists as a sister team to Implementations, but this team will generate revenue on top of the product sale by providing custom implementations. These are usually GMs, Consultants, or Account Executives.

Sales Engineering: These are product experts who also happen to be sales experts. While they don’t cold call or close the sale, they come in to educate and walk the prospect through their primary use cases. Also referred to as Solutions Engineers or Solutions Architects.

Data Science: Any data collection and analysis function, whether that’s engineering data, marketing data, sales data, or any kind of proprietary data.

Support: In some cases, it makes sense for the support team to report to Product, as they generate data that is invaluable to product development.

Labs: When the company reaches a certain size, it makes sense to carve off one or more people to focus on the future of the product, the market, and the industry.

Product Owners/Managers/Marketers: As the company grows and starts offering multiple products or multiple product functions, oversight will become too much for one person. These folks report to the CPO or head of product, who then owns the entire product line.

Be careful not to take on too many product owners or managers. The product team exists to grow the company using the product, and they do this by being a link between several other functions. Having links within links gets painful.

Usually the next step after establishing a product team is to pod everyone up into functional units. This is another case where we shouldn’t ban the practice, but we should be very careful about how we execute.

One of the fruits of success in startup is the luxury to add some redundancy to the org. In other words, we no longer have to do everything ourselves. If we’re creating a product team to take some of the burden of growth off the rest of the org, we shouldn’t undo that by spreading that burden back around the company with functional pods.

Product works a little like development in this regard, where if we lose a developer or someone goes on vacation, we don’t take the total hit because someone else can step in. When we pod the org around product functionality, we open the possibility of creating this same risk across each product or part of the product.

Thus, if we do pod the org, keep the pods flexible. The product team should be able to work across any product or part of the product, and apply at least some of their product, market, and industry knowledge anywhere they’re needed, at least temporarily.

Joe Procopio

Written by

I’m a multi-exit, multi-failure entrepreneur. Building Spiffy, sold Automated Insights, sold ExitEvent, built Intrepid Media. More about me at joeprocopio.com