March 29, 2024

Mistake #4 – Everyone Owns The Product, No One Owns the Product

Ad hoc requirements lead to products that try to serve all, but serve no one at all.  But too many companies from start-ups and early stage to established companies develop inferior products because the products are defined via an ad hoc structure and process.   Just a few of the examples that I have seen include:

  • A salesperson or executive returns from a meeting with a prospect or client and directs an engineer or developer to work on a specific (and urgent) feature to meet the prospect’s or client’s need.
  • An executive walks by a developer and suggests an idea they thought about over the weekend.  In one company at which I worked, we called these “drive-by” requirements.
  • Developers sit around discussing “cool” features that they could put into the product and pick the coolest ones to include.

In any of these cases, the engineer ends up working on the suggested feature or capability as they have no clearer guidance.   This ad hoc approach to defining products leads to a number of problems that result in ineffective and unsuccessful products.  These include:

  • Features get partially done and then the dev team is off working on the most recent urgent request.
  • Feature creep occurs and the product release continuously gets pushed out to a later date.
  • No one has a clear vision of what features are being developed and therefore not everything gets properly tested, resulting in defects and poorly functioning features.
  • Conflict occurs amongst team members as each person thinks their idea for a future should have a higher priority.
  • New features only get partially defined, so what gets developed is incomplete and does really meet the market need.

The end result is a product that does not adequately meets the needs of the market place and diminishes its chances of success.

This problem occurs because everyone thinks they have the right to guide the direction of the product, but in reality no one really owns the product.   And this occurs because there is no structure and process in place to receive, vet and prioritize market requirements and then communicate these as clearly defined requirements to the development team.

In a start-up environment with a very small team, you can often get by with shared responsibility as long as there are regular discussions around product development, but even then, your small team needs to agree upon how requirements will be managed, prioritized and communicated as you receive them from the market.   As the company grows, you need to establish a clear owner (typically a product manager) that has decision authority on the direction of the product.

All companies will benefit from having a clearly defined requirements management process and designating an owner for each product that is responsible for ensuring this process is followed.

Speak Your Mind

*