ProductFTW #28: The Product Development Organization of the Future

There are two unmistakable trends that are disrupting how we think about product development in the current market:

1. The end of “Zero Interest Rate Percentage” (ZIRP) financing is forcing companies at all stages to deliver more value with fewer resources (particularly software engineers).
2. The development tools leveraged inside and outside of traditional ‘code’ are growing increasingly more sophisticated, and it’s not just AI.

These trends will have a harmonic rather than dissonant effect on how we think about accelerating the process of designing, delivering, and measuring good product outcomes. However, it will require a change of mindset from both leadership and individual contributors alike when it comes to how teams collaborate and use the new tools.

Improve the Tools, Don’t Resist Them

If you’re finding the current moment intimidating, you’re not alone. I could barely use ChatGPT, even months after every other post on LinkedIn was telling me I’d be left behind if I didn’t use the latest 10 AI apps that had popped up in the previous week. You’d also be correct in assessing many of these offerings as ‘not ready for prime time’ when it comes to a serious production application rather than individual tasks.

That said, the change is real and we should embrace it. After all, the same things were said about the cloud rather than physical data centers, and real-time business intelligence tools rather than offline spreadsheets. Nobody wants to go back to the days of needing to shrink wrap software onto packages of floppy disks and distribute in stores for a “release” rather than continuous deployment.

Remember, this current wave of Large Language Models (LLMs) is nothing more than better data management to enable complex content generation. It’s a progression on what has been possible with Software-as-a-Service e.g. CMS, CRM, and A/B testing platforms – all of which product teams have come to embrace over the past decade. This content can also include source code generation itself, and several tools are emerging that sophisticated engineers and product managers can integrate to “test and learn” new customer-facing features without writing any new code at all!

Consider the T-shaped Team as a Convergence of Skillsets

The concept of “T-shaped” means someone with a good combination of generalist skillsets and one deep specialism. This has already manifested itself in advocacy for a “product engineer” as a developer who owns large parts of design and outcomes rather than just code, and Zach’s previous discussion of how technical a PM should be. 

The rise of these new tools combined with the fall of engineering capacity is a perfect storm on which to practice these ideas. It doesn’t mean PM and developer roles should no longer exist, but there’s an emerging case that each cross-functional team could have an equal ratio across design, developer, data, and PM specialists with T-shaped skills allowing pairing or any two roles to either build a new component or redeploy existing ones via prompt, component, or data engineering.

Putting this into more explicit practice, the team of the future could very much look like this:

• Product  T: manages stakeholders, deploys features, prototypes new components
• Engineering T: hardens new components, manages  architecture,  orchestrates data flows
• Data T: manages data pipelines, language model tuning, and BI reporting
• Design T: generates assets, conducts research, runs tests using prompt tools

Each of these roles will need to be proficient at prompt ‘toolchains’ across multiple domains. Consider that just these four roles could cover the product remit that might have taken a dozen roles across multiple teams to do just five years ago!

Advice for Ambitious Product Leads

Just as engineers aren’t expected to know assembly language to develop good features anymore, we are entering a world where product and design roles won’t need to know code in order to develop these same features. That said, everyone needs to understand enough about ‘how things work’ to produce good outputs from these tools that will lead to good outcomes. If you’re the PM on a team, it may mean you are increasingly in charge of the customer journey, feature development, and deployment from a set of engineering-managed components and integrated prompting tools.

I highly recommend that everyone in a product role learn Prompt Engineering to generate production assets (code, designs, APIs, modules, etc.) in collaboration with their data and engineering peers.

As with the future teams described above, Leadership roles will also become more T-shaped. The current debate about “Chief Product and Technology Officer” may well become moot as this role, alongside traditional CIO and Data roles, converges on a “Chief Digital Officer.” In many ways, everything old is new again, even if the methods and capabilities increase with each generation!

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.