Building the right product vs building the product right 1


wrong product

wrong product

Starting a company is hard – doubly so for people attempting to do so part-time, without OPM (other people’s money), or without a clear vision of what exactly they are building. Creating a technology company is more than just ensuring that you are using the best language or development framework – the important part of the phrase ‘technology company’ is company. Do not build a ground-breaking VCR cleaning product – it may be fantastically optimized but no one will use it and no one will pay for it.

The reason that the phrase is build the right product, then build the product right is that this is the order in which it should be done. Doing anything worthwhile requires that someone consume your output – service or product. Even more, you will not have a business if this market does not pay you for what you are doing. All businesses require money to survive – even nonprofit/not-for-profit require grants or government money; this is a fee for service that just happens to come from someone other than the end user.

Too many technology companies focus on the actual build process, trying to optimize how they are creating their offerings. Not nearly enough time is spent on ensuring that what they are building is something that people a) want and b) will pay for. Both of these are critical and companies will not survive without both.

“What about free services?” I hear the yells and cries of outrage. Yes, there are companies offer free services and do well with this. My response is, “Sure they do, as long as the venture capital lasts. After that, however …” Business must have money to run, whether from user fees or VC funding. This is the critical part of the phrase above – the left hand side, build the right product. The right product does not refer to the intrinsic nature of the product – it refers to a product for which people will pay.

This is also why a minimum viable product (MVP) is so critical for businesses – it is a version of the product which has the minimal set of features that the business feels is necessary to appeal to the customer. It also is a great foundation upon which to build the better version of product; people that are using your product and paying for it will let you know what it should have, what it is missing. This is the purest, most accurate form of market research – it is really the only research that is worthwhile because it shows you what people *are* paying for, not what they *say* they will pay for.

Building the right product is critical; however, even if you have the right product, your company can fail if you build it poorly. If your product has too many defects or missing features, you will waste the entirety of your research and business development. Therefore, once you know that you have the right product, you must ensure that you are building it correctly and efficiently, and in a user-friendly manner.

What this means in practice is that you need to pay attention to things like the

  • user interface (everyone has to use your service or product – the simpler it is to use, the more that people will use it, provide feedback on it, and most importantly, talk about it)
  • quality (notice that I do not say testing – you can NOT test quality in. Quality starts from how you define what you are building and, optimally, creating directly against these tests. It also means that no defect can ever sit around because “feature <x> is more important” – defects sitting around, particularly ones that users can see or complain about, are like a cockroach on a buffet table; yes, it is only a tiny little thing but once people see it, they will not be talking about how many salad toppings you have or how good the roast beef is)
  • experience of your people (to build the product right – correctly and aligned to business needs – you need to have people that are experienced enough to be able to understand the business and how what you are producing will solve the problems in this domain. There is no business domain in which your product development people can not get a moderate familiarity quickly; however, this has to be a priority for them. You will not succeed here by having people that are not interested in learning or that do not have enough time and resources allocated to them to learn. Any reduction in this area is true false economy – it is also one of the crippling weaknesses of pure outsourced product development. Your investments are completely wasted once the people that your vendor uses are assigned to another company or leave; in the case of offshored developers, turn-over rates are such that you can easily expect to repeat your domain familiarization annually at great cost to your company)

I will be talking in later posts about how to deal with the details of this phrase; however, to start, ensure that you have an active market that is willing to pay for your product. In addition, you should look at how you create and dispense your outputs – make certain that you are doing so as efficiently as possible.

What are some of the problems that you all have seen in either side of this process?
———————————————————————
Image courtesy of Kevin Dooley / flickr.com

Are there better choices for funding than venture capital?
Technology stack showdown - LAMP

Leave a comment

Your email address will not be published. Required fields are marked *

One thought on “Building the right product vs building the product right