PinPoint Performance Solutions Blog (Legacy Content)

What may be obvious to some is not so clear to others.  Quality assurance and usability testing are not same.

My current project work has placed me in the role of usability test participant rather than usability test moderator or usability test developer.  Much of this has been by choice because I think it is good for usability professionals to take a step back and place themselves in the shoes of the test participant.  There is much to learn from being a test participant.  The knowledge I've gain from being in this current role has created topics for future blog posts, but today I want to talk about one important thing I learned in regards to test methodology - the form of testing implemented plays a role in the kind of test data that is received.

I'm not sure if the folks I'm working with are using different terminology (where they say "usability testing", but they really mean "quality assurance" or vice versa) or if there is confusion over the definition of the two terms.  Quality assurance and usability testing are two completely different forms of testing and by defintion they produce two totally different forms of test data.

It breaks down to this:

• Quality assurance tests the suitability of a product.  In other words, is it ready for use and free of bugs or errors (OK, minimal bugs and errors).
• Usability testing tests the usefulness or performance of a product as it applies to the end-user.

Please note, when I say "products" it can also mean software applications, web applications or websites.

I'm sorry to say that the test I'm participating in is a quality assurance test, not a usability test, despite what the moderators say.  We're running test scripts and tasks to record results, but there is very little study into what the end-user's emotional response is to the application or overall performance related to basic tasks.  We're simply finding bugs and reporting them to the developers to fix.

If you are in the process of setting up your own usability test, be clear about your objectives and the data you want to record.  Do you want to measure the suitability of your product or its usefulness?  The type of test you implement will produce different forms of data which you can act upon.

A reader took me to task on a recent blog post I made where I ranted about how bugs and workarounds shouldn't be acceptable or "a way of life".

Patrick Neeman at Usability Counts made two valid points in his response to my post that resonated with me:

1. Test early and test often
2. We live in a beta test world

These two things, among other strategies, will help mitigate usability issues. 

The best example, currently, of living in a beta test world is Google Chrome.  Companies like Google make no bones about the condition of their applications as they are developing them and preparing them for a final release.  It's clearly in Beta - it even says so on the download page.  I'm even using a beta version of the blogging platform I'm using to write this very post.  Believe me, it's far from perfect.  However, the strategy is to let the users be the testers and give them the opportunity to take a form of ownership in the application's further development.

There's nothing wrong with this strategy and I often encourage it among the people I work with.  My point is if the business conditions allow it, do upfront due diligence to make sure the application you are putting out there has a minimal number of bugs, errors and usability issues.  Having these problems only hurts end user performance, if you are expecting them to use the application right away.  A buggy application only slows people down and keeps them from the work they intend to do leveraging the application.

I appreciate Patrick's feedback and I appreciate his willingness to let me comment to his post.  Lesson learned for me is to not vent and blog at the same time!

Forgive the rant, but I'm speaking from experience.  When it comes to technology in business, I believe do it right or don't do it at all.

Over the years, and especially in recent months, I have encountered many proprietary applications not ready for their debut and falling short of their expectations.  Good intentions are there but the applications rolled out to the end-users with much fanfare, who are expected to use them and leverage them to their advantage in their daily work, fall flat.  Instead of full functionality, speed and efficiency, end-users encounter bugs, slow downs and errors.

Sadly, bugs and inefficiencies in applications get passed off as being acceptable and part of the design, development and deployment process.  It's not fair to make your target audience or end users unknowingly be your beta testers.  They shouldn't have to put up with such frustrations if they are being asked to use what really boils down to be a prototype application to do their work.  They should be able to use the application with minimal or no bugs and it should work the way they expect it to. Applications should support work performance, not be a barrier to work performance.

I understand that it may be nearly impossible to release a flawless application.  However, rather than put the end users through this trouble developers and stakeholders should take the time to conduct user-centered design, do quality assurance and build an objective usability test where beta testers can contribute in a meaningful way to find the bugs that are "show stoppers".

Find he bugs, fix them and release.

In the end when a fully functional, working application free of major bugs is released it will work as intended and boost productivity and performance in the workplace.

The team at Virtual Hosting brought to my attention a recent post they made to their blog on how to improve the usability of your website.

Test your Website: A 57-Point Checklist for Maximum Usability

This impressive list provides links to supporting content on the web that I'm sure will burn up your Delicious bookmarks.

Enjoy!

I can't take credit for this post, but I found it very useful and interesting nevertheless.

The top 8 mistakes in usability (and companies investing in it)

When companies create products, especially technology products, the intentions are well placed but often fall short of being useful.  The reason they fail is some companies don't do the right amount or the right kind of research in the early stages of design and development.

The things that stood out to me in the linked post are the context in which the research is done in relation to the product or service being proposed by the company and not being completely objective in their approach.

For every success (iPod) there is at least one failure (Newton).

The Web 2.0 world we live in has been beneficial in creating a community of users that share their thoughts and opinions on the quality of just about anything ranging from websites, books and music, to services provided by vendors in their local.

The power is in the hands of the end-user and they now have a voice. Even more powerful and more prevalent on the web is the power of groups. A fundamental paradigm has adapted itself online in the world of Web 2.0: People tend to buy, use, do and think the way their peers do. In other words, there is a human need to fit in and be among people much like ourselves that we often follow the trend so as not to be left behind or seen as out of touch.

Ratings are often the means of expression of preference in the Web 2.0 world. It's easily understandable by all. Something rated "1-star" is often deemed as bad while something given an "A" or a "10" is deemed as good or excellent.

If you intend employ a ratings system in the design your software, website or web application be sure to choose a system that is not only understandable, but objective.

The more common system is referred to as a Likert Scale. It's a 5-point scale similar to the following:

1. Strongly disagree
2. Disagree
3. Neither agree nor disagree
4. Agree
5. Strongly agree

Anything more than 5 points tend to muddy the waters of objectivity. The more choices, the less absolute the values will be. For example, in a 10-point scale where I say "1" is bad and "10" is the best, I may interpret "7" to be OK while another person may say "8" is also OK. Well, which is it?

The Likert Scale is the better choice when implementing a rating system, but it does have it's pitfalls. I find the 5-point Likert Scale to lack objectivity when you give the end-user a list of many things to rate. The trend usually produces a traditional bell curve where most of the choices fall under the rating of "3" - neither agree or disagree.

If you want your end-users to commit to a choice, do a 4-point scale such as the following:

1. Strongly disagree
2. Disagree
3. Agree
4. Strongly agree

By removing the middle choice you avoid neutrality and create greater objectivity. Greater objectivity means better usability to the community of users.

I was happy to see a post by Peter Abrahams at IT-Director.com on the Future of Usability Testing. The reason I was pleased to see this post was because it backed up my assertion from what I feel to be a credible source that usability and user-centered design during the conceptual and development phases of software, website and web applications, should be a holistic process.

By holistic process, I mean to say that the usability of the application should be linked to the business need. The business need can mean two things - one for the developer and the other for the customer.

As an advocate for usability, I find that user-centered design and usability applied throughout the development process lowers costs both before and after the application is released. During concept and development, user-centered design and usability under an agile methodology will lead to shorter time frame for the development phase, thus lowering development costs.

If there's one thing businesses love, it's lowered costs!

For the customer, a usable application means less support. Ease of use will allow them to be productive with the application and spend less time trying to train themselves how to do certain tasks. If an end-user can be self-sufficient in their use of the application, acceptance and productivity increases thus making the technology purchase a worthwhile investment. If they are able to complete their tasks quickly and efficiently with the application this can translate into lowered costs for the customer. The same is true for the developer. Money going toward support resources to handle "how-to" questions can be diverted to resources that tackle tough technical issues.

Since launching this blog I have written about this topic extensively. Here are some past posts on this subject:

• Maintaining User-Centered Design in Agile Software Development
• User-Centered Design and Agile: Why Can't We Be Friends?
• User Centered Design, HCI and Agile Development Compatibility

I think it will take some time for business leaders to have a meeting of the minds with developers on the need for usability, as demonstrated by the panel discussion that Abrahams reported on in his article. When that will happen it is hard to say, but the trend appears to be moving in the right direction.

I recently stumbled upon a blog post at BNET.com that discusses how innovation can go overboard. I'm all for innovation. It's what makes living in this day and age exciting. However, too much innovation does little to improve our lives and leaves us frustrated and confused.

When we innovate products, especially software and web applications, we should be asking ourselves a number of questions.

• Will the change or introduction of a new feature or function solve a specific problem for the end-users, address a specific need or help them overcome a challenge?
• Is the introduction of the new feature of function in response to a need or is it for the sake of innovation? In other words, are you trying to "keep up with the Jones'?"
• Are the increased production and development costs that come along with introducing the new feature or function going to pay off in the short-term or long-term?

These are just a few questions that come to mind, but I'm sure there are many more. Overall, the question that should be asked; is the innovation needed? If not, leave it be. As the blog post so eloquently states, if you start playing a game of one-upsman-ship, your competitor will inevitably go back to tried and true methods of simplicity and use that as the primary value proposition of the product. Focus on what made the product successful and the value it creates for the end-user. In the end, that's all they really care about.

I know I mostly talk about the usability of technology in the workplace, but have you ever stopped and wondered about many of the products we use on a daily basis where we can likely suffer from buyer's remorse. Buyer's remorse is usually associated with high-ticket items like property, cars and computers, but I think it can extend to everyday items too.

One of the reasons we suffer buyer's remorse is because we find that the product is not usable to us in our daily life. It does not meet our needs or help us overcome the obstacles and challenges we face. When the product falls short of our expectations, we then begin to feel we have been cheated or made a bad purchasing decision.

Most technology provides an opportunity to play around with it or a trial period. Stores offer demos of computers and peripherals. Software developers offer 15 or 30 day trial ware versions of their applications and some websites offer a day or week of free access to their service all in an effort to let you get a feel for what is being provided and give you an opportunity to decide if you want to make a full purchase.

Note: I'll give cell phone companies some credit for their 15-day trial period, but I still don't think that's long enough. I once bought a phone where I think after the 16th day I was fully committed to taking a hammer to it. Day late and a dollar short... I guess.

Still, there are some items we buy that don't offer a trial period or a test drive and I would love it if we could find some way to make this happen. Here are are some items I think need to be "test-drivable":

• Toasters - it never fails that light and dark settings for toast vary from toaster to toaster. I want to be able to test drive a toaster before I buy it and find the one that makes perfect toast.
• Shower Heads - I can't stand low-flow shower heads! I'm all for conservation and not being wasteful, but do I have to spend twice as long in the shower to accomplish what I could do in half the time with a regular shower head? Oh, do I long for the days when a high-pressure shower head had enough force to knock you to the back of the shower wall.
• Telephones - Cell phones and land lines, it doesn't matter. What I hate about not being able to test drive a telephone is that you can't hear what the ringer sounds like until you purchase the wretched thing, bring it home and get your first call. Most telephones have some of the most annoying ringers I have ever heard. If the logic is to make the most annoying, vertebrae piercing sound on the planet to get my attention, I'm afraid these manufacturers have done the opposite (on me, at least). When I come across these phones I usually disable the ringer and screen my calls.

Oh, I'm sure I could come up with more, but perhaps we could leave that for another day.

I guess the lesson learned out of all of this - especially if it has to do with technology or a product that is supposed to improve the quality of life or work - is to let folks take a test drive if you can and within reason. I think if we do this, we'll have less buyer's remorse and get better feedback from the end-users. When we take their feedback into account, we can build better products.

Besides, the greatest benefit will be the time I get back if I don't have to return these items to the store!

The lack of posts on this blog have been due to some recent projects taking up most of my time. Because of this, my blogging has suffered. Perhaps I need to heed the advice of this blog post, set up my own blogging regimen and work it into my schedule.

Until I get a regimen developed, my blogging will be more spontaneous. When an opportunity where people can learn about good usability and design techniques presents itself and I can quickly write about it, I should take it!

A current project where I deliver training on a content management application to groups of new end-users presented such and opportunity.

I didn't design the interface of the application - I just train on it. It seems when the application was designed, the developers didn't fully understand the end-user and how they understand the content they manage. The application I teach allows end-users to set up metadata for their document and then upload their document (file or files) to the system. To do this, the button that activates this function is labeled "Add Content".

Sounds easy enough.

If an end-user wishes to upload a new version of the document, the button to activate this feature is "Add Rendition". This has been a source of confusion for many end-users. During the training sessions I deliver, I usually find myself spending more time explaining what the developers meant by the word "rendition" rather than demonstrating the actual functionality.

Note: the functionality of adding content and adding a new version of previously uploaded content is the same.

The reason for the confusion is the naming conventions end-users reference (in their minds) when they wish to work with content. Adding content is easy to understand. They upload a file or files to the system if it has not been added before. Adding a rendition is not so easy to understand. I'm not sure why this is confusion and I need to investigate it further. Rendition must have a completely different meaning to the end-users than the word version. Given the opportunity I will mention to the developers that the labeling of these functions is in need of review. We might have a simple fix on our hands, such as renaming or relabeling a button, that will reduce a great number of support calls and e-mails.

Through my training I have been able to uncover a usability stumbling block and it all stems from improper labeling and lack of understanding the end-users. The lesson learned is that developers need to understand how their end-users think, especially what they call things. Say what you mean, be literal and match what the end-users think.

I never considered myself and early adopter. Everybody seems to have one in their life, either among their circle of friends or within their family, but I'm not one of them.

A little more than a year ago, Microsoft released its Vista operating system. When the product launched I didn't run out right away and install it on my company's PC's. I waited on the sidelines like a lot of other people and stuck to what I knew worked for me, met my needs and what I was familiar with. I didn't want to change to something that was unproven and had little to no guarantee that it will work with my software and other hardware devices.

Late last month, I upgraded one of my computers and chose the Vista OS. Actually, I had no choice with the box I purchased. It was either Vista or nothing. After a year in service, I thought it was time to give the OS a try. To me, the change was inevitable. Eventually I would have to make the change because Microsoft will quit offering XP and will no longer support it in the near future.

A recent PC World article titled Why Users Hate Vista explained how change in an operating system is more emotional (to the end-users) than technical (for the IT personnel). When it comes down to it, any technical change for an end-user is emotional. It's human nature to resist change. Just ask my friend who wrote a recent post on his blog about change. Bottom line: people are creatures of habit and will prefer to keep things status quo. At minimum they will be very selective about the amount of change they are willing endure.

In business and the IT world, change is unavoidable if you want to remain competitive. I don't recommend change for the sake of change, but if it improves your business processes it should be implemented with thought and consideration for the end-user. After all, it is they who will be leveraging the technology to drive the business processes that bring about success.

How does one implement a technology change despite the emotional reaction people will have to it? The answer is Change Management.

Here are some tips and thoughts I have on this subject:

• Focus on the people - consult with the end-users. Include them in the decision making process when making changes to the technology they will be interfacing with. Work with them to identify their needs, the obstacles they wish to overcome and their overall objectives.
• Communicate strategic messages - discuss the reason for the change and solicit feedback. Clarify how everyone will be involved in the change and give them ownership in the implementation strategy.
• Communicate and train - provide ample notice and support for the new technology measure the results. Above all, maintain open lines of communication to allow end-users to ask questions and voice their concerns. Address them promptly.
  

If you take careful consideration into what you are doing and who you are doing it for, you can be confident that the change will be embraced and implemented as it was intended.

As I reflect on 2007, two things emerged that defined the work we did at PinPoint and the causes we advocated or rallied against.

1. Focusing too much on things that are less important.


2. Making things bigger or more complex than they really are.

Focusing too much on things that are less important
In September, I wrote about about how I thought some product developers tend to concentrate too much on a single aspect or set of features and not enough in other areas. Some work with a local company last year reminded me of this post and I was part of the effort in redesigning their corporate website. One of the company leaders who was spearheading the project spent a lot of time making sure the home page looked a "certain way." It was, to say the least, a very frustrating obstacle to get the this company leader to overlook.

The reason why it was so frustrating was the assumption this person had about his audience. It was very difficult to get him to understand that not all users, especially his target audience, make their way to the home page of their website first. Understanding how their audience searches for information was key, and more than likely they would search for the products they were selling and not the name of their company.

Assumptions about your target audience can lead you down the wrong path. In the case of this company, it delayed the launch of the site. When you make assumptions about your audience or focus too much on less important aspects about a product, you delay you chances of success or miss opportunities all together.

Making things bigger and more complex than they really are
In June I wrote a post that was somewhat similar to the previously mentioned post.

It bothers me when I engage potential clients who are reacting to the actions of their competitors. Though it is rarely spoken, it often comes back to "Everyone else is doing it, why aren't we?"

I'll heed my own advice and not make this point any bigger and more complex that is should be. The point is companies and product developers should be doing what works best for them, what they know best and what meets the needs of their end-users.

----

One final note, I'd like to say it has been an pleasure writing this blog since its inception in late 2006 and throughout 2007. This year, you will notice fewer posts on a monthly basis. The focus of PinPoint Performance Solutions in 2008 will be quality over quantity. Thank you for reading and I look forward to your feedback and input on future posts in 2008.

Rik Catlow of Rikcat Industries posted to his blog 5 Ways to Make a User Interface Intuitive.

I completely agree with Rik and wish more developers of software, web applications and websites embrace simplicity in the design of user interfaces. I'm sure if you take stock of the applications you use on a daily basis or applications you have used in the past, you'll recall how most of them are confusing leaving you to fumble around just to accomplish a simple task.

Much of this is common sense and when simplicity is chosen over complexity it is not about compromise. It is about being targeted and precise in your intentions and purpose behind your application.

Here are Rik's suggestions on making a user interface intuitive along with some of my own commentary:

1. Eliminate Redundancy: most applications have different ways to accomplish the same task. Reduce the redundancy and simplify the tasks to a select few.
2. Nomenclature & Contextualization: I sum this up as a controlled vocabulary and proper labeling. Don't be cute with titles linking to other pages or sections in your website or web application. If you have a section with a list of links to other websites or links to e-books and presentations, don't call it "The Pit" or "Library". Call it what it is. Call it "Links". This is about knowing your audience and you must speak their language in your application's interface.
3. Consistency: the overall look and navigation of your application must be the same throughout, no matter where a user is in the application.
4. Protect Screen Real Estate: if you work with many people on a project, there is a tendency for others to jockey for position to take up space on the screen for their pet projects or areas of interest. Make it clear that it is about the end-users and what is relevant to them.
5. Testing: make sure you test your application or website with actual end-users. Run a series of tests from paper-based, wire frame prototypes to functioning prototypes. Testing need not be complex, but it must be objective.

Along with these 5 suggestions, here are a few books and a link to a useful web article that will help you create a intuitive user interface:

Books

• Information Architecture for the World Wide Web by Louis Rosenfeld and Peter Morville
• Don't Make Me Think by Steven Krug

Web Articles

• Why You Only Need to Test With 5 Users by Jakob Nielsen

John Dvorak, columnist for PC Magazine, published an interesting article about Microsoft and the reason as to why he thinks there are many flaws in their software.

I like the title of his article: The Problem with Eating Your Own Dog Food.

I'm not here to say what's right or wrong with Microsoft or add fuel to the fire in the Mac vs. PC debate. I'll leave that to other people to battle.

What I found interesting about Dvorak's column was that it highlighted a point I've been advocating to my clients and the readers of my blog: When testing your products, don't recruit your own people to be your usability testers.

It's almost like preaching to the choir or a parent telling their child they are a talented singer when in reality they are not. Dvorak attributes this to "Eating Your Own Dog Food". If you have ever wondered why a company like Microsoft tends to have so much trouble with their products, Dvorak offers his theories as to why. Most of the problems are cultural and indicative of a large company who has been a dominate player for many years.

I know it may seem natural to have your own people test and use your products. After all, they have a vested interest in its success, don't they?. With success comes the guarantee they'll have a job tomorrow. That may be true, but what about the opposite side of the coin? If a company with a product that has cornered the market for several years and become its bread and butter has employee usability testers detect flaws, would rocking the boat be in the employee's best interest?

Remember, your product testing will be better served if you put it in the hands of actual end-users and work to document their feedback. If you are a company that become established in your field and have become a consumer of your own products, it may be time to stop and ask yourself, "Are we eating our own dog food?"

Recently I found a great blog post on the subject of design. When we hear the word "design", what does it mean? Frank Spillers tells us in his post titled What is Design? (Yes, all 10 definitions!) at his blog, Demystifying Usability.

I hope Frank doesn't mind, but I commented and offered another definition of design (bringing the list to 11) that I think fits well within the framework of usability. How about instructional design?

When it comes to products, whenever we are able to support the transfer of knowledge in a logical, objective fashion or make it easier for people to learn how to operate products and apply them to their work, we increase the level of satisfaction surrounding the user experience. I know that usable products are supposed to be intuative and easy to learn in and of themselves, but there is always a need to support learning.

Just another definition of design to add to the list and I'm sure there are more to come.

Normally I speak about integrating technology in business processes at an enterprise level, but today I thought I'd speak about startup companies and their acquisition strategy. I'm not necessarily talking about startup companies acquiring other companies or technology. I'm talking about the innovation or product the startup company creates being acquired by a much larger company like a Google or a Microsoft.

PinPoint Performance Solutions primarily focuses on the conceptual stage of product development linking the needs of the end-user to the product being developed. The end result is a usable product meeting their needs and expectations. I met with a colleague this past week who works with clients to identify whether or not their products are viable in the marketplace. In other words, he does the due diligence and research to make sure there is a marketplace for the product. I'll admit some failure on my part. My colleague helped opened my eyes to a crucial compenent of product development.

He told me a story of a client who invested a large sum of money into a custom software application for the construction industry. A well-known software company approached him about acquiring the application, but when the offer came in it was far below what he originally invested in the development of the application. He was in the market to inevitably sell the application, but he never thought he would lose money in the process.

The reason why the offer was low was the software company was unable to purchase the application and market it immediately due to how it was developed. The coding was not compatible with their coding and a lot of back engineering would have to be done in order to make the application compatible with their other applications.

The lesson - if you are in the business to generate revenue off of your work or to potentially sell your application to a larger company, plan for it. I'm not saying that you need to make your product the exactly the same way a potential buyer would make it, but you do need to know what they and the rest of the market will accept and what is valuable to them if the opportunity to sell presents itself. It needs to be usable to them in order for them to find any real value in it.

So, just as you would develop an exit strategy in your business plan you need to prepare for an acquisition strategy in your product's marketing plan to create value in your product when a potential suitor arrives.

Jakob Nielsen recently published his findings on intranet usability and found marked improvement since his last study.

The report is very detailed and worth reading, but as I was reviewing it a few things came to mind:

1. I've had quite a bit of experience with corporate intranets in my career. It's ranged from intranets having very little information and being of little use to intranets with so much information they are disorganized and too difficult to find anything. No two are alike.
   
2. Just because an intranet is only seen by a select group (employees in a company, for example) it doesn't mean web usability guidelines and standards don't apply. People transfer their expectations of what they find on the web and how it functions to the intranet they are using. The only difference is the information on the intranet they are consuming is meant for their eyes only.
3. Finding information on an intranet quickly and efficiently will help increase productivity. Nielsen does an excellent job illustrating the costs (both in terms of lost and gained productivity) associated with intranet usability.

Intranets are a wonderful tool for managing and transferring information in an organization, but don't forget they are subject to the same usability standards we come to expect from the web and applications we use on a daily basis.

My friends at Valitics are running a series of posts on their blog about web optimization. One of thoses posts is on web optimization and usability.

Head on over to their blog to see how they view this subject. As an item of interest, you may also find my recently published white paper on Search Engine Optimization (SEO) and Usability useful as well.

In a recent post I talked about integrating Web 2.0 in your organization. One of the statements I made was that when you implement Web 2.0 technologies you should expect to encounter bugs, poor interfaces or poor usability. In other words, beta releases will most likely remain in beta or a work in progress (WIP). It's simply par for he course.

BNET recently published Perfectionists Despair: Digital World “Always in Beta” to their website. It's a nice, quick little article that hits the following points:

• Speed will trump perfection. Time to market is crucial in the digital world and a "not ready for primetime" software or web application won't necessarily be held against you (author's note: BlogRush is a prime example).
• The pace of business is so fast, there's really no way you can release a flawless product if you expect to make any kind of significant impact.
• Consumers (end-users) aren't really consumers any longer. They are now your beta testers or your usability test subjects. Learn from them and engage them in a meaningful conversation. You'll learn more about your product and how it relates to them than you'll ever know.

I for one am glad that the acceptance of betas are in the digital realm. Imagine if betas were acceptable in the cars we drove or the household appliances we used. Life would be more exciting, but much more dangerous than it already is (depending on your lifestyle).

Mr. Godin hit the nail on the head yet again in his recent blog post:

Seth's Blog: Alarm clocks

In the past I have maintained that some product developers, especially developers of technology products, have a tendency to concentrate too much on a single aspect or set of features and not enough in other areas. In Seth's example, he basically says we'd have better alarm clocks if it weren't for people developing them concentrating too much on marketing.

That's not say that marketing is a bad thing. In the end, it illustrates product development is more about what people want out of their products and what they can do for them and less about how many can be sold. If you give people what they want, marketing will come much easier.