Great product managers are aware of these common software problems.

Today, I’m doing a speed run through all kinds of problems that occur in software development.

I’ve been coding software since I was 16 or 17, so it’s been 23 years now.

I wanted to give a good overview of all the things that can happen in a software project, and also provide potential solutions.

I’ve categorized these problems into why, when, what, how, and with who.

These are distinct problems that start from the inception of a project: why we’re working on something, the connection between the user and the actual development team, when we’re dealing with prioritization, what the actual subject matter is, how the process works, and who the people involved are. Let’s dive in.

Why: Understanding the Purpose

1. Everything is considered important

Sometimes, stakeholders say they need everything done immediately and perfectly. This usually indicates a problem with prioritization.

Solution:

Validate features through user feedback
Define a clear product strategy
Prioritize based on impact and effort

There’s a caveat, though. Sometimes, everything truly is important.

Sometimes you have software that works through different steps, and all these steps are crucial.

We once built a huge form builder software where we had to work through many forms because all this data was required to give a result to the user.

In such cases, the only way to cut down the scope is to make each individual package smaller, perhaps by simplifying the UX while still containing all the necessary information.

2. Developers don’t understand business goals

When this happens, developers usually focus on the wrong stuff and aren’t working on things that actually make an impact.

Solution:

Communicate business goals clearly
Repeat key messages (at least seven times, as per “High Output Management”)
Align development priorities with business objectives

I learned from the book “High Output Management” that you should repeat something around seven times before it sticks. It’s about repetition of what this thing actually should do.

3. Features never get done

This can happen if product managers have a certain estimation in their head, thinking a feature will be fast and important, but the developers don’t see it the same way.

Solution:

Bring the development team closer to users
Implement regular user interaction for developers (e.g., customer support rotations)
Align feature priorities with user needs

I’ve heard of a company where every developer has to work in customer support one day per month. When that happens, they actually see what’s important to the user and have a much better picture of what to focus on.

When: Timing and Prioritization

1. We build shortcuts now, rework later

This is a typical thing called technical debt. It’s even something that can be done deliberately. Technical debt means you’re taking a shortcut now to be faster, but of course, later on, you need to clean it up.

Solution:

Schedule regular “cleanup days” (e.g., every Friday)
Dedicate specific periods for refactoring
Create a separate team focused on addressing technical debt

I’ve seen all of these approaches in my life as a software engineer. And I have to say, there is no silver bullet. All of them can work, and all of them also have the potential not to work if they’re not backed by the right people.

2. One module is late, others are done

This is just a symptom of improper planning, which usually comes from the fact that people don’t know exactly how this thing will be built in the future.

Solution:

Improve planning processes
Identify tasks that can be parallelized
Ensure clear communication about system constraints

You start in an agile way, you don’t know all the information, you haven’t looked at all integrations, maybe there’s something coming from the user side that you didn’t know before. It’s usually just something where we didn’t understand something before, and now we have to deal with that.

3. Integrating with third-party services causes delays

This is something I’ve seen a couple of times. It happens when there’s something in the software that needs to integrate with another system, and this other system is like a black box.

Solution:

Conduct thorough research on third-party services before integration
Include substantial buffer time in project timelines
Plan for higher risk when dealing with external dependencies

Usually, when there’s an integration in a system, it needs to have a huge risk factor planned. If this doesn’t happen, you’re just working against a deadline that’s kind of a wish deadline.

4. Deadlines are missed, and nobody knows why

This is just a matter of poor estimation and risk management.

Solution:

Implement stagger charts for better estimation
Regularly review and adjust timelines
Be prepared to cut features to meet critical deadlines

There’s one solution called stagger charts, which are pretty cool. Every month, we go into every software project and estimate what we can achieve in the next month. Usually, these things always get delayed a bit. It’s just a question of how much.

What: Subject Matter Challenges

1. UX is too complex, and we’re not pushing back

This is a common problem because UX designers love to make something pretty, and they usually don’t care so much about how fast it can be built.

Solution:

Involve frontend developers early in the UX design process
Encourage open communication between designers and developers
Balance aesthetics with implementation feasibility

I’ve seen this many times where UX designers build something really nice, but it’s very hard to implement. There’s only one solution for this: involve a front-end developer early on and have them push back against the UX.

2. Developers work on a ‘bike shed’

This is an interesting principle you can look up on Wikipedia. It’s where a disproportionate amount of time is spent on simple, low-priority tasks rather than complex, important ones.

Solution:

Clearly define and communicate priorities
Implement deadlines to motivate focus on important tasks
Regular check-ins to ensure alignment with project goals

This happens with developers too. They see something they can grasp or like, and they put way more time into this than into the actual important features. The solution? PMs need to control this and make sure the team stays focused on priorities.

3. Features take longer than estimated

This is something that just always happens. As a product manager, you need to embrace this because estimations for software projects are usually always worse than initially thought.

Solution:

Add buffer time to estimates
Conduct more thorough research before coding
Use tools like stagger charts to improve estimation accuracy over time

It’s just a rule of nature. You can mitigate this a bit by adding more buffer time or doing more research before you code.

4. Shipped features are incomplete or buggy

This usually happens when there’s a disconnect between the planning, testing, and development team.

Solution:

Improve acceptance criteria
Enhance communication between planning, testing, and development teams
Map dependencies between subsystems

What we need here are better acceptance criteria. This could mean that PMs need to know better what’s required because sometimes they don’t know, and then they don’t write proper acceptance criteria.

How: Process Problems

1. Development feels reactive, leading to burnout

This happens especially if developers don’t see the exact goal or motivation and only get fed one task at a time.

Solution:

Set clearer long-term goals
Improve planning processes
Show developers the bigger picture, not just individual tickets

While this can work for a while, especially with a highly engaged PM, it’s usually better to have longer-term goals and more coherent planning.

2. Demo days are frequently missed

This is normal, especially with smaller teams or when there’s no one pushing for it.

Solution:

Consistently reinforce the importance of demos
Make demos a habit by setting regular, immovable demo days
Implement a feature freeze before demo days

Usually, these things don’t work on the first try. We have to always motivate the team and remind them of the importance of demos.

3. Developers struggle with estimations

This is just a force of nature. Developers will estimate 16 hours and think it’s 16 focused hours. But in reality, it’s always more.

Solution:

Add buffer time to developer estimates
Use historical data to improve future estimations
Implement estimation review processes

We just have to deal with that and plan accordingly.

4. Production bugs are frequent

This just happens, as my senior engineer once told me. There’s no way around it. You will have bugs.

Solution:

Implement thorough testing processes
Have a clear on-call schedule for quick bug fixes
Enhance code review practices

What’s important is to stay calm and find ways to fix them quickly. In my previous team, we would make a schedule for who’s on call to fix things if they break during a release.

Who: People and Communication Issues

1. Team member is unexpectedly slow

This happens to the best product managers, and they don’t know why a team member isn’t performing.

Solution:

Conduct regular skill level assessments
Set clear expectations for each team member
Provide necessary training and support

Usually, it comes down to a skill level assessment. Maybe they don’t know the skill level of that developer, or maybe the developer is a genius but hasn’t worked with this exact technology before.

2. Questions go unanswered

This often happens when a developer is working on something that builds on someone else’s work.

Solution:

Establish clear communication protocols
Assign responsibility for responding to questions
Create a culture of prompt support

Usually, you can find the Git logs and figure out who worked on it before, but that’s not always possible. It needs to be clear who’s there to help.

3. Information doesn’t flow properly

Sometimes a stakeholder wants information, and the team gets asked, but they don’t know, so they ask the next person.

Solution:

Define and document clear roles and responsibilities
Review and update responsibility documents regularly
Implement efficient information sharing systems

This is just a problem of information flow and hierarchy. We need to define clear roles and responsibilities in a document and review it ideally every week so that everybody’s on the same page.

4. Status updates are not readily available

If a stakeholder asks about the status and only the assigned dev knows, it’s a process problem.

Solution:

Implement a clear ticketing system
Ensure all tasks are continuously updated
Train developers on the importance of status updates

We need a clear ticketing system where all tasks are continuously updated. If they’re not updated, it’s a lack of discipline on the developer’s side, which can be taught.

What kind of problems have you seen in your career, and which ones did I miss? Let me know in the comments below. And if you want to see the video where I compare my velocity to someone else’s, check out the link in the description.

Pain is information - and that’s the same in software development.

Yes, I hope you don’t only rely on pain to make decisions. But once pain appears, there’s something to learn.

It can help us create more efficient, effective, and enjoyable development environments.