When I started my career at Microsoft I was on the QA team and I distinctly remember a conversation with one of my team leaders that went something like this:

Me: “We’re responsible for the quality of the product.”

Test Manager: <Laughs>

Me: “Then who owns it?”

Test Manager: “Everyone – the job of the QA team is simple to accurately measure the state of product quality consistently.”

It’s true.  The QA team does not own quality. They are there to accurately measure the state of quality during the development cycle… but real quality is actually a perception formed in the minds of your customers about your product.  The reality is that everyone who touches a customer at your company is responsible for their perception of your products quality. Now lets examine how different roles own quality.  Because no one reads really long posts I’m going to break this up.  Hat tip to Jim Holmes… who inspired this series.

Part 1: Sales and Developers

Sales & Account Managers…

You own the first touch before I may have even seen the product. If no one gets back to me for weeks then I assume that no one would follow up on any issues I may encounter.  If three people get back to me with duplicate questions I assume you can’t properly coordinate basic ownership… let alone product development as a company.  I recently had a company that didn’t get back to me… but did add me to their company mailing list.

Once we’re working together (customer & sales) I form my product expectations from you.  If you say I’ll get the following features & values out of the product then my expectations have now been set.  I’d rather be told “No, we can’t do that today.” than “Yes” followed by months of frustration trying to make the product do something it really can’t do.

This means you have to know the value props and product features like the back of your hand… and be OK with being honest when the answer is “no”.  As a customer I’ll respect you more for that… and will probably come back when I realize a competitive sales person miss-represented the product to me.  You do not have to know how the engine in the car works… but you have to be able to tell me if I’ll go 0-60 in greater or less than 10 seconds.

Developers/Engineers…

You are building whatever it is your company sells and you’ll be the first ones blamed (right or wrong) when something goes bad for a customer.  Entire books and blogs have been written on the subject, but I’ll try to highlight a couple of bullets:

• Demand clear expectations or clearly set and communicate them yourselves for overall functionality, performance, security, and scale.  Get clarification on what the non-happy path behaviors should be.  Never assume. An assumption is a customer that’s going to have their expectations set incorrectly.
• Write tests that validate these expectations.
• Write code you would be proud to print in a book.
• If you see complex code… simplify it. Understand what complex code looks like… there are any number of tools available to you that you can use to measure it with.
• Understand the problem your feature is solving, the user goals,  and WHY you are building what you are building.

Part 2 looks  at Consulting Services & Support.