Menu background


We’ve Adopted Modern Practices, Why isn’t Product Development Great yet? - Challenges in Product Development

Level-up Engineering TeamLevel-up Engineering Team

Receive our best content two weeks before anyone else! Join 5000+ tech leaders and managers.

We’ve Adopted Modern Practices, Why isn’t Product Development Great yet? - Challenges in Product Development

The speed of software development is at an all time high - the quality of products released hasn’t kept up though. 

What are the challenges in product development that hold companies back?

Gil Broza, Value Delivery & Agile Leadership Expert, gives actionable advice for leaders who want truly great product development. He emphasizes the importance of putting people first, creating a culture of continuous improvement and a lot more.

This blog post summarizes the main points of episode 90 of the Level-up Engineering podcast hosted by Karolina Toth. Make sure to check out the full interview through your favorite podcast platform or Youtube. 

This post covers:

We are arguably at the best state of software development and product development in the history of the human species. But product development still isn't great yet. Why could that be?

Software development has certainly evolved, especially in terms of speed. In my 30 years in the industry, I've seen development accelerate at a remarkable pace. But faster doesn't always mean better. Despite the speed, the quality of products hasn't necessarily improved.

Many companies aim to create successful products, but they often fall short. The pace of development hasn't aligned with solving user problems or delivering real value.

Let's talk about the people. My philosophy prioritizes people first. While some attention is given to processes and products, it's not always enough. Worker engagement remains a challenge, especially with the shift to remote and hybrid work arrangements.

Success in software development requires continuous improvement, yet many companies seem to plateau after adopting certain methodologies. Few actively strive to enhance their practices throughout the development lifecycle. New methodologies like Scrum, Kanban, and DevOps emerge, but their adoption is often partial and not fully effective. Implementing changes can create unintended consequences, leading to stalled progress.

Another challenge is the recent backlash against Agile methodologies. While some larger companies abandon Agile, they fail to replace it with a coherent alternative strategy for successful product development.

Oftentimes, there's no unified approach to developing successful products, which is concerning for the industry's future success.

How should leaders start improving their software delivery system?

I’m advising every leader I work with to focus on a value delivery system. It's not just about engineering, product, or design—it's about the whole package.

First, leaders need to grasp the full scope of their value delivery system. Sure, it's easy to understand what it produces—be it a product, service, or solution. But who's part of it? This is where many leaders fall short. 

Imagine your product is like a movie. You reach the end, and there's a long list of credits—everyone who contributed. It's not just the obvious roles like actors or directors; it's the designers, project managers, architects, even the ones who deploy and maintain the product. That includes managers higher up the ladder too, up to the VP or CTO level, depending on their impact.

Now, let's talk about the way of working. There are visible practices, like daily meetings and backlog management. But the real game-changer is the mindset—the consistent choices you make. For example, committing to not making promises a year in advance or prioritizing collaboration.

Understanding that your system operates in non-obvious ways is crucial. Even when leaders are aware, they might take a linear view. But in reality, every choice made in one part of the flow ripples throughout the system.

So, if you want to make improvements, think systemically. Don't just focus on one area like engineering. Enhancements impact the entire system, so collaborate with peers to understand potential impacts.

Change starts with people, not just processes. It's not about running daily standups better; it's about creating an environment where people behave meaningfully. Factors like personality, mindset, environment, incentives, and team dynamics all play a crucial role.

Can you give us some examples on how to put people first in practice?

Let's start with a fundamental truth: businesses want deliveries, products, revenue, and profit. That's a given. Now, how do we achieve that? Do we stick to standardized processes, reminiscent of waterfall thinking? Or do we embrace total autonomy, a free-for-all approach?

Neither extreme is perfect. So, what's the alternative? Putting people first. This concept draws from servant leadership, a philosophy that's been around for over 50 years. While it's not widely popular, it's effective. Agile emphasized this by prioritizing individuals and interactions over processes and tools.

Putting people first means considering their impact or being impacted by decisions. It's about starting decision making with the people in mind.

What does this look like in practice? 

  • Transparency is key—people need to understand why decisions are made.
  • Boundaries should be explicit to avoid surprises when crossed accidentally.
  • Encouraging personal growth and responsibility is another aspect. It's about empowering individuals to respond to situations, not just cope. 
  • And let's not forget humanizing everyone—staff aren't resources, managers aren't robots, and users aren't just numbers. They're human beings with lives, preferences, and emotions.

When we humanize everyone involved, we create products that truly serve people's needs and desires. After all, isn't that what it's all about? It's not just about money—it's about making a meaningful impact on people's lives.

What mindset does a leader need to have when thinking about achieving better product delivery?

Mindset = how we make choices

Let's start by clarifying 'mindset.' It's a term that's gained popularity, thanks to the book on growth mindset versus fixed mindset. But what does it really mean? In simple terms, it's about how we make choices.

There are some key elements to mindset: what we value and what we believe, which shape our operational principles—the standards guiding our decisions and actions in various situations. For instance, if we believe we're not entirely sure what users want, we might prioritize adaptation. This belief gives rise to principles like developing incrementally or seeking collaborative input.

These principles inform our practices, roles, meetings, and tools, shaping our way of working. It's crucial for leaders to be intentional and explicit about the mindset they want their team to embrace. 


This approach may sound familiar—it's essentially agile thinking, but you can label it however you like. The focus is on defining principles like collaboration, simplicity, and transparency, then translating them into actionable tactics with input from the team.

Consistency is also key. Reflecting on our choices and adjusting as needed is crucial for maintaining alignment with our desired mindset. It's not easy—it requires diligence and sometimes external guidance to stay on track.

For leaders seeking to optimize their team's way of working, it's essential to identify the mindset that aligns with company goals and gradually transition towards it. 

Effect on company culture

When you maintain a consistent mindset over time and among different people, that's what forms your culture. While mindset and culture are distinct concepts—culture being more permanent and slower to change—they're intertwined. People may adopt different mindsets for different tasks or projects, and this has been the case for decades.

For instance, traditional project management often prioritized predictability—making promises about timelines and budgets. But when projects went off track, agile principles were often employed to rescue them. The approach shifted from strict predictability to agility, showcasing the flexibility of mindset within the same organization.

In your value delivery system, it's valid to have different mindsets for different phases—whether it's integrating a new company or adapting to evolving market demands. The key is to be deliberate and clear about how you want to move forward, leveraging existing mindsets where appropriate rather than starting from scratch.

What are the next steps of perfecting your value delivery system?

So, what I've been doing for the past few years is focusing on how to reach a genuinely beneficial target state tailored to each organization, not some cookie-cutter ideal imposed by a consultancy. The aim is to enhance the fitness-for-purpose of our systems, not just patch immediate issues.

I've developed a model comprising 10 incremental and sequential strategies to guide this process. It's like improving overall health rather than just fixing a single problem. For instance, rather than aiming to run a 5k race right away, we focus on improving various aspects of our lifestyle—diet, sleep, mindset—to sustainably achieve that goal.

These strategies are aimed at making the entire system healthier and more aligned with its purpose. They provide leaders with a manageable sequence of actions, unlike the overwhelming prescription-based approaches prevalent in our industry.

Instead of prescribing an ideal or best practice, my approach emphasizes understanding the current level of fitness-for-purpose and gradually improving it through targeted actions. This approach acknowledges the unique context of each organization and offers a sustainable path to transformation over time.

It's a departure from the one-size-fits-all approach and is particularly valuable in today's landscape, where leaders are bombarded with conflicting advice and need tailored solutions that suit their specific circumstances.

How should a team or a company start with fitness for purpose? 

The initial step is to establish a coalition of leaders—a diverse group from various departments within the value delivery system—who will dedicate their attention to driving improvement initiatives. This coalition ensures that improvement efforts have a dedicated focus and are not just a mere checkbox on executive agendas or yearly goals.

Once this coalition is formed, the next step is to conduct a current state assessment. While this can be done individually, it's recommended to perform it collectively as it reveals differing perspectives on what constitutes success. This conversation also sets the stage for identifying the organization's current level of maturity.

Now, let's say the assessment reveals that the organization is at, for instance, level three. In this model, strategies are incremental, meaning that prerequisites from lower levels should have been implemented. These prerequisites could include portfolio management to avoid overwhelming teams, ensuring suitable organization structures for mission alignment, establishing decision-making protocols, and maintaining system stability.

If any of these prerequisites are lacking, they need to be addressed before advancing to the next level. The aim is to ensure that each strategy is sufficiently implemented before progressing further. For instance, if the organization struggles with decision-making protocols, efforts should be directed towards establishing clear decision-making channels.

Once these foundational strategies are in place, attention can shift to level three strategies, such as fostering safety, teamwork, and collaboration, refining release cycles, and enhancing team involvement in planning processes. These strategies are also approached incrementally, with qualitative indicators used to gauge readiness for progression.

What sets this model apart is its adaptability to diverse organizational contexts, whether employing homegrown or off-the-shelf methodologies. It provides a structured yet flexible framework for driving meaningful changes tailored to each organization's specific needs and challenges.

We have created a group within the organization with enough leverage to actually make changes, and there is actual tangible improvement within the organization. What do you suggest after? How often should companies look back at their delivery system?

It really hinges on the pace of change within your business and its size. For instance, in a large product development organization with hundreds of employees, implementing the strategies I've outlined takes time to permeate through the system and influence dynamics. In such cases, conducting reflections every few months might be appropriate.

However, for a smaller operation like a nine-person startup, where decisions can be made swiftly and everyone is closely involved, more frequent reflections, perhaps every three weeks, could be beneficial. This allows for quick adjustments and ensures alignment across the team.

The key point here is to emphasize systemic review rather than solely focusing on individual team retrospectives. Our industry tends to prioritize local optimizations, with different departments and individuals working in silos. But for real impact, we need to break free from this fragmented approach and strive for cohesive, integrated efforts.

How should we imagine the strategies working in real life?

I had a client I worked with extensively in 2022. Despite only spending a total of about 10 days with them throughout the year, it was a transformative experience. When I first engaged with them, they were attempting to implement Scrum, a methodology they had introduced eight months prior, but which was struggling to gain traction.

The organization comprised five development teams and a content team, and the situation was chaotic. To address this, we formed a team of improvement leaders, primarily consisting of managers and a few team leads. Together, we focused on refining their way of working, making adjustments to team structures, and redistributing responsibilities to foster progress and reduce bottlenecks.

One significant challenge we tackled was decision-making, which was overly centralized around the founder. While many were hesitant to confront this issue, as an outsider, I was able to address it directly. Surprisingly, once the founder understood the principles behind Scrum and the importance of decentralized decision-making, he readily embraced the change.

We also worked on stabilizing the system, drawing on Agile principles such as limiting work in progress and fostering collaboration among teams. While efforts to improve safety and teamwork began earlier in the process, they truly gained momentum once the system became more stable, around four months into the initiative.

A pivotal moment came during a company offsite, where I facilitated activities aimed at enhancing collaboration and teamwork. This event proved highly effective, fostering a sense of unity and shared purpose among team members.

As time progressed, the organization's progress became evident. By August, they embarked on a new project, the New UI, which represented a significant departure from their traditional waterfall approach. Despite initial apprehensions, the team embraced agile development practices, gradually building and iterating upon the UI design.

By the time my engagement concluded after a year, the organization had achieved a remarkable transformation, reaching level four of improvement. This success was not the result of exhaustive efforts on my part but rather the dedication and commitment of the management team and staff. Once trust and collaboration were established, progress accelerated, culminating in a truly self-sufficient and agile organization.

Bonus gift from Gil

I'd like to offer something to our listeners. I've prepared chapter one of the book for download. It's not merely an introduction or a teaser; I've titled it "The Big Picture" because it serves as both the foundation for the rest of the book and a comprehensive overview of the model's key points. I crafted it with busy readers in mind, recognizing that not everyone will have the time to read the entire book. However, with just 20 minutes, you can gain enough insight to initiate meaningful change.

You can access chapter one at the following URL:

Feel free to share it with your colleagues to align on the same mental model and have a written reference of our conversation.

About Gil

Gil has over 30 years of experience in the software industry. For the past two decades, he's been dedicated to helping leaders improve their organization's practices, especially focusing on Agile methodologies. Gil's approach is practical and adaptable, tailored to each company's needs rather than sticking to a specific Agile doctrine.

Outside of work, Gil's biggest hobby is solving puzzles. Whether it's word puzzles, math problems, or jigsaw puzzles for relaxation, he enjoys the mental challenge. He often shares this hobby with his wife, solving puzzles together and even attending conventions dedicated to their shared interest.

Check out Gil’s website, his book, and feel free to reach out to him via LinkedIn.

Let's build awesome things together 🚀

At Apex Lab, we're experts in end-to-end digital product development. Our remote-first company operates with a flexible schedule, allowing us to help clients tackle difficult challenges worldwide.

Want us to build your next idea or upgrade your existing product? Our experts cannot wait to work with you. Get in touch with us and let's make this happen. 💡🚀