Product-Centric Teams Fuel Growth

Aeri Shan
4 min readFeb 17, 2021

I was originally going to title this something like “Why you need a whole-systems approach to marketing” but I decided to keep it more general because this is about taking a whole-systems approach to product development (PM and Engineering) and marketing. The functions are very naturally interdependent in start-upville. If you are embarking on a product-led growth scenario, I think this type of thinking is essential.

I worked early on as a web developer in the publishing industry which is by it’s nature incredibly end-user focused. I got very interested in how people interacted with websites and spent a lot of time on UX and usability. The end goal of any digital product is either revenue or impact or both and so it was perfectly natural to view UX and Usability as a marketing problem set (or vice-versa) and the engineering side as the tools one uses to solve those problems. As just a quick example, sometimes half the reason you may have acquisition or activation or conversion problems is because you have bad usability.

I’ve learned some really cool things about efficient product development and marketing along the way. When you’ve gone all the way from architecting a technical solution to productizing it to coding it to marketing it, you start to realize how inextricably connected all these disciplines are and how often they are approached in a disjointed way. Too often I as the product manager need to talk to Sarah to make sure we can engineer this and to Lisa to make sure she understands our customers and can market it appropriately. Yet, ideally, we are all really on the same team. No really, we should be working together daily. We should sit next to each other in the office. Crucially, we should all understand why we are doing any of it. The customer. This fuels growth.

Since I’ve worked for some smaller organizations I’ve had the opportunity to both cover all or many of these bases myself and also to do just that: work daily with my counterparts be they marketers, PMs or Engineers rather than treat them as siloed functions that interact through a formal process. This will be a pretty familiar situation to most start-up veterans but it’s easy to lose sight of this as you move up in scale. Yet it can make a huge difference in how these functions connect and react to changing needs in an agile way.

One of the core concerns in many roles I’ve had is self-serve revenue, from qualification and nurturing through activation and conversion. These are complex multi-variate issues with many moving parts. Change functionality and you may increase or decrease activation, but not if you change the UI to alter certain calls-to-action and only on Mondays between January and June. And it could be that that activation is short-lived and overall your conversions go down and/or you are actually decreasing lifetime value. It’s a lot to handle and really benefits from combining multiple perspectives.

I’ve also worked for much larger companies like Sun Microsystems where one variable impacting another was irrelevant as long as Bob got his TSP reports on time. As a marketer or product person this is the height of frustration — knowing that you can affect some important variable, say increase activation, if Sarah’s engineers could just implement feature X or modify feature Y. At times I’ve had a quarterly number and my compensation depended on it. Yet too often it’s extremely difficult to even have a dialogue that brings the work into the fuller context. Sarah is left believing my request is unreasonable and is viewing this strictly as “we have no time for that engineering” while Lisa doesn’t believe this is a marketable thing at all. And you know what? I the PM or Growth Marketer or whoever is chasing this down, may in fact be wholly or partly wrong. Each of us only has some pieces of the data necessary to shape this decision. We need the framework of customer-centricity to guide us.

There are many ways to structure this and each company’s unique culture is a critical consideration. But to generalize it’s useful to think in terms of product-centric teams. Groups of people from the different disciplines to work on a product as a team. Whether this is the whole product development function or merely representatives obviously depends on your scale, but I’ve seen both scenarios work well.

With product-centric teams we can have a dialog to help shape decisions, and when that dialog is not a one-off but a routine and we’ve developed a rapport and understanding of our respective roles, we can put in play all the variables that will better inform what’s possible, what’s necessary, and what’s effective. And most importantly, we can focus on the customer and use that as our north star. That integration and built-in cross-functionality can give everybody valuable context and purpose to drive customer-centric growth which is the key to long-term sustainable product-led growth.



Aeri Shan

Story-teller. Data-wrangler. Product visionary. Empath. Non-binary human.