Building Complete Products
Have you ever used a web site or service that "wasn't all there?" Maybe it looked good and did something useful, but it required that you go elsewhere to finish what you were trying to do.
Travel-booking sites didn't used to have integrated maps. (Hard to believe...) Then some clever person (probably a travel-site product manager) realized that customers had a problem locating the motel they were booking, and that they were plugging the street address into Mapquest or Google Maps. Pretty soon every motel listing had a link to pop up a map, and eventually the maps were embedded into the listing itself. The product was more "complete", and it solved the customer problem more effectively.
Likewise, one of the hazards in developing packaged software is the failure to make a "complete product." Simply put, if the product in the box does the whole job, then it's complete. If it requires the user to go elsewhere to do part of the job, then it's not. An example is a data management product that requires a database engine to be in place - in this case, there may be a big IT cost (acquiring and/or connecting the database, and supporting it from a server) every time a customer buys the product. A less dramatic example would be a web design application that requires you to go online and buy templates or content - the app is forcing the customer to finish assembling the product.
Incomplete products can be justified many ways:
Each of these rationales can be very compelling from the development point of view, and may seem to be a good business strategy. But from the point of view of a customer who simply wants to start working, it's a lot less convincing. Typically, a tech enthusiast customer can handle an incomplete product - and may actually prefer something that can be tweaked and added-to. But a less sophisticated customer with no interest in customizing, downloading or extending an application is much less likely to take the trouble to use an incomplete product or service.
(There are times when "incompleteness" can be a business virtue: AutoCAD is an example of a product that succeeded because its open architecture encouraged add-on application development. But in that case, the product became a platform, and the opportunity to "complete" the product fell to the add-on developers.)
Here's an example of a web service that goes the extra mile, as opposed to the "not quite complete" approach of YouTube: Blurb is a service that publishes custom books that its customer submit. The beauty of Blurb is BookSmart, a free application for designing a custom book. It can be installed easily onto a Windows or Mac PC, and it provides a variety of templates for assembling books of all sorts. Finish your book, publish it to the Blurb web service, and your bound book arrives in the mail a few days later.
BookSmart is downloadable software. There are countless other examples of web applications, widgets and engines that can be plugged into a web service to "complete" it, like the embedded travel site maps. Why not put a good text editor onto that text entry page, instead of just a text box? The beauty of the web is that the user need never know that a site includes code from two, three or many vendors. As long as it gets the job done.
One caution: This isn't an argument for bloated products. If you try to make a product that is "complete" for every possible customer, you'll end up with a 100-blade swiss army knife that satisfies no one. Instead, the trick is to identify what is the minimum "complete" product for your target customer, and build that.
Customers are usually more interested in achieving an outcome than assembling a tool or figuring out a complicated process. This is true whether the product is a consumer electronics device, a PC-based software application, or a web service. There's a place for flexible, build-it yourself, or incremental products, but only when they are matched with customers who are willing to tinker with the product. For the rest of the world, "complete" is better.
Travel-booking sites didn't used to have integrated maps. (Hard to believe...) Then some clever person (probably a travel-site product manager) realized that customers had a problem locating the motel they were booking, and that they were plugging the street address into Mapquest or Google Maps. Pretty soon every motel listing had a link to pop up a map, and eventually the maps were embedded into the listing itself. The product was more "complete", and it solved the customer problem more effectively.
Likewise, one of the hazards in developing packaged software is the failure to make a "complete product." Simply put, if the product in the box does the whole job, then it's complete. If it requires the user to go elsewhere to do part of the job, then it's not. An example is a data management product that requires a database engine to be in place - in this case, there may be a big IT cost (acquiring and/or connecting the database, and supporting it from a server) every time a customer buys the product. A less dramatic example would be a web design application that requires you to go online and buy templates or content - the app is forcing the customer to finish assembling the product.
Incomplete products can be justified many ways:
"We can supply it at a lower price, and the customers can buy the
modules/content they want."
"We can get the base product done quickly,
then add functionality though modules, later."
"We don't own the engine (or content or web app) that's required, so the customer will have to purchase (or download) it themselves."
Each of these rationales can be very compelling from the development point of view, and may seem to be a good business strategy. But from the point of view of a customer who simply wants to start working, it's a lot less convincing. Typically, a tech enthusiast customer can handle an incomplete product - and may actually prefer something that can be tweaked and added-to. But a less sophisticated customer with no interest in customizing, downloading or extending an application is much less likely to take the trouble to use an incomplete product or service.
(There are times when "incompleteness" can be a business virtue: AutoCAD is an example of a product that succeeded because its open architecture encouraged add-on application development. But in that case, the product became a platform, and the opportunity to "complete" the product fell to the add-on developers.)
Here's an example of a web service that goes the extra mile, as opposed to the "not quite complete" approach of YouTube: Blurb is a service that publishes custom books that its customer submit. The beauty of Blurb is BookSmart, a free application for designing a custom book. It can be installed easily onto a Windows or Mac PC, and it provides a variety of templates for assembling books of all sorts. Finish your book, publish it to the Blurb web service, and your bound book arrives in the mail a few days later.
BookSmart is downloadable software. There are countless other examples of web applications, widgets and engines that can be plugged into a web service to "complete" it, like the embedded travel site maps. Why not put a good text editor onto that text entry page, instead of just a text box? The beauty of the web is that the user need never know that a site includes code from two, three or many vendors. As long as it gets the job done.
One caution: This isn't an argument for bloated products. If you try to make a product that is "complete" for every possible customer, you'll end up with a 100-blade swiss army knife that satisfies no one. Instead, the trick is to identify what is the minimum "complete" product for your target customer, and build that.
Customers are usually more interested in achieving an outcome than assembling a tool or figuring out a complicated process. This is true whether the product is a consumer electronics device, a PC-based software application, or a web service. There's a place for flexible, build-it yourself, or incremental products, but only when they are matched with customers who are willing to tinker with the product. For the rest of the world, "complete" is better.