The Cost of Over-Engineered Processes
As we wrap up the year, I want to take a moment to thank you—my readers and subscribers. Your engagement, feedback, and shared insights have deeply fulfilled this journey. For those celebrating, Merry Christmas, and to all, I wish you a restful and joyful holiday season. Episode 18 is the final episode of Product with JnrJose for 2024, and it feels only fitting to end with a topic close to my heart: simplifying product delivery by addressing the cost of middlemen.
This is Episode 18
In this final piece of the year, I want to address a critical truth that gets overlooked far too often: “It’s impossible to deliver great solutions to customers by building around processes. Great solutions come from focusing on solving customer problems.” This article is inspired by my experience working in two organizations that favored process over problem-solving, and explores how over-engineered processes can hinder product discovery and delivery.
Processes Don’t Solve Problems—People Do
Earlier this year, I engaged with a team in a large organization renowned for its process-heavy approach to product delivery. During a conversation about users not adopting what is built, I asked, “How fast do we identify and respond to users’ needs?” The responses varied, but one stood out: “Our processes are here to ensure quality.”
That explanation, though well-meaning, revealed a deeper issue. The organization was building around processes rather than around customers. These processes were seen as the ultimate path to success, yet they had become bottlenecks. This led me to a crucial realization:
Processes are tools, not goals. They should support problem-solving, not become the focal point.
When we prioritize processes over customers, we lose sight of what truly matters—delivering solutions that make a difference. Processes, no matter how sophisticated, don’t solve problems. It’s the teams, empowered and focused on solving real customer pain points, that deliver impactful products.
The Illusion of Efficiency in Over-Engineered Processes
Over the years, I’ve seen countless organizations add layers of roles and approval steps to "streamline" delivery. Instead of streamlining and create more focused product teams, they would rather create new roles around processes with fancy names. While these roles can be invaluable in project management, they are less effective in product-focused environments where adaptability, creativity, and speed are essential.
The belief that these layers improve efficiency is often misguided. Instead of fostering collaboration, they create:
Fragmentation of Understanding: When engineers and designers are separated from customers by layers of reporting, critical insights are diluted or lost entirely. Solving real problems becomes harder because the people building the solution lack direct exposure to the problem.
Delays in Decision-Making: Each additional layer adds approvals and documentation, turning what should be quick iterations into long cycles of back-and-forth.
A Lack of Accountability: With responsibilities spread across multiple layers, no one owns the product’s success. This leads to misaligned priorities and a diluted focus on the customer.
I’ve learned this lesson firsthand. While working on an API product that was growing in scope, I initially managed the product with a single product manager overseeing all moving parts—partnerships, reporting, and core functionality. However, as the product scaled, it became clear that one person couldn’t manage the depth required for each area without losing focus. Instead of introducing middle layers, I split the team into specialized product teams. Each team, led by a dedicated product manager, focused on specific user problems: one on partnerships, another on tools for operational efficiency, and a third on the Public API.
This decision allowed us to maintain clarity and deliver value without adding unnecessary bureaucracy. Focus replaced complexity, and the product’s growth accelerated as a result.
Processes designed to manage complexity often end up creating it. Instead of solving inefficiencies, they exacerbate them. True efficiency comes from empowering teams to act with focus and clarity, ensuring every decision is driven by user needs and business goals.
A Story About Engineers, Customers, and Problem-Solving
One of the most eye-opening moments of my career came during a particularly frustrating customer complaint. Instead of funneling the issue through multiple teams, I decided to bring the customer into the same room with our engineers and designers. I asked the customer to use the product as they normally would, while the team observed.
The result was transformative. The engineers and designers immediately spotted where the problem lay. The issue wasn’t in the code or design but in how the feature’s functionality was communicated. Within hours, the team had simplified the feature, making it easier to use. By the next day, we released an update. The result? Higher adoption rates and overwhelmingly positive feedback from users.
This experience underscored a key truth: solutions emerge when teams understand the problem firsthand. No amount of process or documentation could have replicated the clarity and speed that came from direct interaction with the customer.
The Marathon Mindset: Products vs. Projects
Treating products like projects is one of the biggest contributors to over-engineered processes. Projects are finite—they have defined timelines and deliverables. Products, however, are living systems that require constant iteration, adaptation, and long-term thinking.
When organizations impose project-based thinking on products, they prioritize outputs over outcomes. They focus on ticking boxes—shipping features, and meeting deadlines—without ensuring that these outputs solve user problems. True product success requires a marathon mindset: clarity of vision, adaptability to change, and a relentless focus on the customer.
Next year, I’ll delve deeper into the difference between projects and products, exploring how organizations can align their processes with the unique demands of product development.
Building for Users, Not Bureaucracy
The essence of agility is not in its rituals or frameworks but in its ability to empower teams to adapt, collaborate, and deliver value quickly. True agility means creating processes that serve the team, not the other way around. It means fostering a culture where experimentation thrives and failure is seen as a stepping stone to success.
Building for users, not bureaucracy, requires organizations to ask hard questions:
Are our processes helping or hindering problem-solving?
Are we empowering teams to act decisively, or are we bogging them down with approvals?
Are we solving real customer problems, or are we just delivering outputs?
By focusing on these questions, leaders can create environments where great products are born—not from bureaucracy but from clarity and collaboration.
2025 Call to Action
As we move into 2025, let’s commit to simplifying the way we build products. Let’s prioritize solving customer problems over perfecting processes. Let’s empower teams to experiment, fail, and learn quickly. And most importantly, let’s remember that great solutions are built not around processes but around the people they’re meant to serve.
Next year, I’ll start by addressing the difference between projects and products, exploring how this distinction shapes team structures, decision-making, and delivery.
To my readers, thank you for being part of this journey. Here’s to building products that matter—products that solve real problems and deliver true value. Happy holidays, and I’ll see you in 2025!