3 Ways ‘Successful’ Projects Deliver Failed Products

Defining ‘Success’ for a product is both essential and challenging.  Many teams slog through projects and deliver poorly-targeted products that leave everyone involved wondering:

Did we succeed?  At what?  For whom?

Product development can run amuck in many ways, but some of the most-common pitfalls are:

  1. not understanding the problem
  2. confusing completing tasks with building value
  3. building a technological marvel

Pitfall #1 – Not Understanding the Problem

Do your potential customers actually have the problems your product solves?  When describing the product vision to a customer, their eyes should light-up and they should say

Yes, I want that!

If your customer does not react the way you expect (and even if they do), now is the time to explore the problem and solution space with them.  Some products are so visionary that customers may not be able to make the leap from their current experience to where the product vision is (e.g. iPod entering portable music player market).  However, the more-likely explanation is that the product doesn’t solve the customer’s problems.  Not every lead will or should be expected to turn into a customer, but the product definitely needs enough customers to support building and operating the product.

Take-away: Listening-to and learning from your customers is the most-important way to ensure the product being developed finds and succeeds-with a target market.

Pitfall #2 – Confusing Completing Tasks with Building Value

Sometimes teams are so happy to get something, anything done that the mere move of a task to the ‘Done’ pile is cause for celebration.  Be careful not to confuse defining and executing a project with discovering, building, and delivering a product that customers value.

project != product

Projects provide many interesting and crucial things to measure:

  • velocity
  • work completed
  • work remaining

However, project metrics only describe whether the project is on-track, not whether the product is.

Product metrics look like:

  • hypotheses tested and validated
  • actual number of users and engagement-level with product features
  • discovery of what product features customers will pay for
  • number of customers’ problems solved, revenue generated, savings captured

Take-away: Executing a project successfully is necessary but not sufficient to build a product that succeeds in providing customers value.

Pitfall #3 – Building a Technological Marvel

Product teams may build a technological marvel before the product’s value proposition has been validated by customers.  This marvel may be built for ostensibly good reasons like the product needs to:

  • scale up-to 100k/1M/10M concurrent customers
  • scale down-to 1 Megabyte of RAM
  • be buzzword-compliant (ok, that’s not a good reason)

If the product actually needs to meet needs like those listed above to succeed from customers’ point-of-view, then technology will be a significant part of the solution at some point.  However, if the product currently has only a few customers, then building sophisticated solution may be pre-mature and carries liabilities.   Because building a sophisticated technological solution usually often increases complexity, a technology-focused effort may both:

  • delay learning from customers what the product should-be
  • hinder evolving the product using customer feedback

Take-away: Building a technological marvel pre-maturely may both distract and hinder the team from building a product that customers care-about.

Conclusion

Watch-out for these pitfalls when executing product-development projects in order to avoid ‘successfully’ delivering a failed product.

We’ll dig into how Lean product development and Agile project management practices can keep product development teams on-track for success in later posts – contact us for immediate support.