top of page
Writer's pictureMark Wheatley

10 Warning Signs Your Company Has a Broken Product System



According to research 71% of software launches are unsuccessful (source: The Standish Group). This eye-opening statistic highlights the many challenges of software development. Whilst various factors can contribute to these challenges, an ineffective product management function will always significantly increase the likelihood of failure.


If the following statements are something you recognise from your own organisation, the chances are that your product team is making some fundamental mistakes in the way it operates.


1. “There are always arguments about prioritisation”


Prioritisation is a common source of conflict and tension. If the wider team can’t often agree on what the team should be working on next, this is a red flag that one or more of the following things may be missing:


  • An effective quarterly planning process, in which leadership, product, design and engineering all participate

  • A ‘product data map’, which socialises the KPIs most important to the business and which ‘product levers’ can be pulled to drive the numbers in a positive direction

  • Proposed solutions and features supported by sufficient levels of qualitative and quantitative data

  • A prioritisation framework such as RICE, Kano, Jobs-to-be-done or TARS. Not adopting a scientific model of feature prioritisation can lead to hunch-based bets that don't deliver value


2. “Our product team is a black box”


If solutions and features appear without prior warning, and the purpose and rationale for those solutions are not communicated to key company stakeholders beforehand, this is a sign that your product function is suffering from 'black box' syndrome. This is one of the most dangerous and damaging problems that a product team can face. The first priority for a product team should be to develop trust at all levels of the company in their ability to deliver. If the product team is struggling to build trust with all its key stakeholders, it suggests the need for a restructuring of communication methods and pre-development processes.


The absence of appropriate product documentation at various stages of the product design process can give observers the impression that the product development is being done in an ad-hoc manner. Implementing a systematic process for documenting each stage of the development process will enable stakeholders to be involved earlier and foster trust in the product team and its ways of working.


3. “Product managers are not regularly talking to users”


The role of the product manager is to represent the voice of the customer within your organisation. If they are not engaging with users, it indicates that they are probably functioning as delivery managers rather than product managers.


The cadence of this engagement with customers is also important. It’s far more effective to talk to users little and often than have big user research projects that go deep but only happen a few times a year. Feedback from users of the product should be taken at all stages of the development process, and there should not be a week that goes by without the voice of the customer being heard.


4. “We measure success by output and not outcomes”


Meeting deadlines is important. However, shipping working software alone is not enough to ensure that your product work is delivering value to the business. The effectiveness of a product team should be measured by their ability to ship effective solutions that drive real business value.


The first step here is clearly articulating what outcomes a software release is designed to achieve. If everyone in the team is aligned on the outcomes that are expected, and those outcomes are measured and reflected upon, you are both creating a working environment that is optimised for learning and driving more effectively towards your business’ ultimate goals.


5. “Our product work is not delivering enough business value”


Even when the product team prioritises customer needs through effective user research processes and user-led design, all product work should still provide value for the business and align with advancing the company's mission. It is possible for product teams to become so customer-focused that they overlook the company's strategic vision and the need to achieve specific high-level business outcomes. However, an effective product team will seek those opportunities that deliver both what customers need and what brings clear business value, rather than seeing it as an either-or scenario.


A great way to facilitate this is to create and socialise a company ‘product data map’. This is a three-level hierarchy. The top-level should be the primary business objectives for the coming year, i.e. MAU, subscribers etc. Underneath these should be the ‘success indicators’ - leading metrics that are proven to generate movement in those numbers, i.e. app installs, new-user retention, subscriber retention. The third level is where the ‘lever metrics’ sit - these are product behaviours that the product team can impact that we know will improve the success indicators. These will vary widely between businesses but could include things like the time the user spends in the product, app store rating, app quality etc. Ideally this would also include the ‘habit forming metric’ which identifies a set of actions/behaviours for new users that correlates to the highest levels of customer retention. A product data map shows which lever metrics help move which second-level metrics and impact core business objectives.


Example Product Data Map for a freemium subscription product
Example Product Data Map for a freemium subscription product

6. “The features we release are not having enough impact”


This is a common issue in product teams that are falling into ‘solution-first’ thinking. If the first documentation that appears to support a project contains polished-looking designs, it’s a safe bet that this could be your problem.


In product work it’s key that enough time is spent in the ‘discovery space’ before moving forward to execution. Adopting a more design-oriented approach will ensure that user research underpins your solution ideas: work starts with a clear definition of the problem you are trying to solve, qualitative and quantitative insight is used to strengthen this understanding, and low-fidelity prototypes are the first output from the design team. Building a feature on this solid foundation of understanding will dramatically increase your chances of success.


7.  “Our product roadmap is always wrong”


The use of roadmaps is often a pain point within companies, both for product teams who will often resist pressure to commit to a long-term release plan, and for the wider business who will grow frustrated when both the content and schedules change. If you are working in a B2B/SaaS environment and there’s a need to share these with customers, constantly shifting dates and features can be particularly problematic.


An effective quarterly planning process can be a great way to improve predictability an confidence in the output of your team, as will ensuring an agile development process where detailed, pre-defined scope is not favoured over regular releases of working software.


The format of the roadmap itself can also dramatically improve their effectiveness by better managing expectations around delivery. For example, the granularity of roadmap content can vary depending on the level of uncertainty and the timeframes involved. Releases planned for the next quarter where some product discovery has already been completed should be expressed in more detail than a release 12 months away which has not yet undergone any product discovery. Using expanding-timeframes will also be helpful (i.e. Q1, Q2, H2, Next year). Including the confidence level for each release period will also help better manage expectations.


Example of a more effective roadmap format
Example of a more effective roadmap format

8. “I can’t access product data without negotiation with gatekeepers”


The democratisation of data within your company is one of the best ways to ensure that your entire team feels empowered and involved in making your product successful. If accessing product data is difficult and requires help or permission from specific individuals, the team may eventually stop relying on data to inform their decision-making process. Product managers are often very busy, and if accessing data takes up too much of their time, they may choose to allocate that time to other activities. Having a good, modern product data reporting tool is a great way to ensure that data is used frequently and effectively.


9. “Our Product Managers just aren’t good enough”


If your product managers seem to be struggling, it could be due to some of the process and system failures mentioned in this list. Optimising your product processes may be sufficient to help them succeed. However, it is clear that exceptional product managers are not created overnight. They are developed over time through effective coaching and development.


One of the most common complaints you will hear from product managers is that they are too busy to prioritise personal development. This is likely because they are not shown a clear path for improvement, with simple next steps that allow them to make a start. Often, the HR function lacks a model that defines the specific skill set required for product managers to excel in their roles. By introducing a product-manager specific skills model, such as the Product Competency Framework, you can create a simple but effective coaching and development plan for your product managers.


10. “Our product is lacking direction”


Complaints about a lack of direction may arise because your product team is trying to achieve too many things at the same time, and spreading the teams focus across too many initiatives. Or the answer may be even simpler - you are just not communicating the product direction in clear enough terms. The best way to do this is with a Product Mission Statement.


Mission statements are a directional compass that provide a visible reminder of the ultimate objectives your product team should be working towards. Here’s some examples of mission statements from well known companies:


  • Google: To organise the world's information and make it universally accessible and useful

  • LinkedIn: Connect the world’s professionals to make them more productive and successful

  • Nike: To bring inspiration and innovation to every athlete in the world


This mission statement can be expanded into a broader document that adds more context and detail on things like the competitor space, and what will make your product offering unique. When facing a difficult prioritisation call, this documentation can work as a useful tool to help your team filter out those ideas that while interesting and seemingly viable, do not contribute enough to your company’s core objectives.


If you are struggling with any of these issues you might benefit from a product spike - a root and branch deep-dive and review of your product ways of working. Read about our product spike approach here, or get in touch for a conversation to learn more.


Recent Posts

See All

Comments


bottom of page