Maciej Mróz Personal Blog

Because why not

Nov 18, 2012 - 4 minute read - Product Development

Right is not the same as intuitive in product development

Some introductory note: I’ve written this post before reading Lean Startup by Eric Ries. Recently I finally found time to do it and … I wish this book existed five years ago :) The problems I describe below are not unique. If what you read resonates with you in any way, go and read the book - it explains these ideas in a lot greater detail, touching on some more complicated subjects like product life cycle and company structure. Anyway, here’s the post, only slightly edited.


You have new great idea. Or perhaps someone else has the idea and you are just executing it. Doesn’t really matter. It goes into production, team gets assembled and a year later they come back with a working product. The developers did their job correctly, the product works as intended, incorporates most of the changes management has introduced in the past year, and everyone says it’s ready. So it gets released and … nobody buys it. Customers don’t want it, and you have no idea why.

Everything seemed so perfect a year ago: the business plan, market research data, focus tests … whatever was used to ‘prove’ the idea is right. The product is right, and of good quality, so you start refining it, adding features, buying marketing campaigns … all with little to no effect on the product performance, and all taking even more effort. Sounds familiar? Been there, done that :( Ok, what now? Blaming begins?

Unfortunately, in corporate environments that’s very often the case. Smart people jump off the ship before it crashes, and when failure is not tolerated, it’s really the only thing to do: abandon the project before it fails. Except it’s not the solution. But, what actually went wrong? Just one thing, and it’s a mistake so common it’s not even funny: treating assumptions as truth.

Want a list? Ok, here are some typically made in the product development process:

  1. The business plan is actually worth anything.
  2. The focus group is representative of your customers. In other words, you know what customers want.
  3. Value of the product shipped a year from now is the same as if it was shipped today.
  4. Your customers perceive quality the same way you do.
  5. Your customers value product features the same way you do.
  6. You know who your customers are before you actually start selling the product.
  7. It’s industry best practice, so it has to be put in the product.
  8. It works for the competition, so it has to work for you, too. Now, a catch: some of these assumptions can turn out to be true. But which ones? Even if you have hard data (i.e. from past project) this data is by definition about another customer, another product, and another time. While anything you know shout not be ignored, it also shouldn’t be blindly trusted. What we want is fix the process and make it look less like gambling with huge amounts of money. Can it be done? Yes, but that requires thinking a bit on the unothodox side :)

The goal is not to eliminate mistakes, that’s just impossible. It only pushes you further the road outlined at the beginning, and solves nothing. What you should do is in fact a lot simpler:

  1. List your assumptions.
  2. Prepare a plan to deal with them - prioritize your development around confirming or disproving there assumptions. Note: customer value of product feature is also an assumption!
  3. Ship early, ship often. “A year from now” is not really different from “forever”.
  4. Constantly adjust - you don’t know what product you are going to build. It’s not your decision really, it’s the customers who decide.
  5. Don’t be afraid to kill products. It’s better than continuing death march and waiting for the miracle to happen. Spend your effort where you actually have the chance to succeed.

The product development process should never be about getting everything right at the beginning. It’s about getting some stuff right, and being able to clearly identify the good and the bad things. It’s about learning and adjusting. If it looks like adapting agile software development methods to product development, well … it should. It all really comes down to dealing with uncertainties, instead of pretending they are not there.