Lack of Feedback

Right now lots of product development teams aren't getting the feedback they need to build the right capabilities for their users. The problem ranges from no data being collected at all to data being collected, but is not easily accessible to everyone working on the product.

Wildly Inaccurate Estimations

Currently estimations can feel like magic numbers and it's usage can often be misinterpreted by different stakeholders and team members. Some view it as complexity and others can't help but convert it into an indication of time-to-completion. This leads to unrealistic expectations and can cause frustration, stress, burnout, and ultimately, poor performance.

Furthermore, there or other reasons for making estimates difficult, such as: not using a consistent estimation framework that can be compared across time and having the software that enables this without digging through every previous task that matches the profile of what you're trying to estimate.

Too Many Well Intentioned, but Ultimately Unproductive Meetings

Too many meetings can often lead to a lack of productivity. Additionally, too many meetings can be overwhelming and stressful, leading to burnout and decreased productivity. Interestingly, many of these meetings don't achieve their goals, and the outcomes are often unsatisfactory.

Example 1: Having in-person and non-anonymized retrospective meetings often cause people to hold back from providing honest feedback.

Example 2: Standups turn into monotonous status-reports instead of resolving blockers. It doesn't even do this well because often people are unable to remember every single thing they did. Even if they do, it usually goes in one-ear and out the other.

Over-Focusing on Features

There is a lot more to building features than its functional requirements.

Delivering features include many non-functional requirements such as testing, maintenance, documentation, and more. A backlog that only focuses on the functional requirements can lead to unrealistic expectations of how long it will take to build a feature. These mismatched expectations can often lead to micromanagement, unnecessary stress, decline in motivation, and ultimately, worse user experience if non-functional requirements are skipped to meet timelines.

Overwhelming Backlogs

Backlogs can grow and become unwieldy quickly. This detracts people from updating them regularly as you learn more about your users and priorities change. There are a few reasons for this, such as: Product trying to prioritize Engineering tasks they don't understand or vice versa for Engineering, and the lack of backlog management tools.

Focusing on Velocity Instead of Value

At the moment too many product teams are run based on velocity and measured in outputs.

So many of us have been in this situation where we spend months or years building a product only for it to be scrapped because no one wants to use it after launch. It's really demoralizing and ultimately, a huge waste of time and money.

Instead of focusing on vanity metrics and outputs like number of tasks done or % of sprint completed, product teams need to focus on the value that the product delivers to their users. This is a much better indicator of product-market-fit and product success.

Arbitrary Development Windows (Sprints)

No problem is the same, and equally, no solution is the same either. Some take less time to solve and others take longer. Trying to find the right sprint duration to account for all situations is difficult and ultimately doesn't provide much additional value.

In fact, this can sometimes cause more additional harm. For example, if a developer cannot break a task down any further and it takes longer than the sprint duration to complete, it can be very demotivational to realize you failed to miss the sprint goal through no fault of your own. If this happens too often, it can significantly reduce team morale and lead to higher turnover.