Skip to content

Elevator Speech: Part 1 of 9: Deliver High Quality Solutions…

September 23, 2011

In my first post here I’ll start out by sharing what I call my “elevator speech”. It has evolved over the course of 20 some odd years as I have tweaked and refined it along the way, but it has remained relatively the same and is the gestalt of what makes me tick. This is a blog, so I’m just going to write the way I talk and anything I say is based on years of being in the software industry and from being full of opinions…

Deliver high quality solutions on time that are innovative, delight customers, win reviews, and disrupt competitors; all while having fun, being ethical and transforming the business.

The first part of this is “deliver high quality solutions… Why start there? It is one of the most important parts of the equation in my mind. First of all one must actually deliver something, it then has to be of high quality, and it has to be a real and valued solution.

Deliver: It can’t sit in the oven baking forever, can’t be a prototype, or be demo-ware. It has to be something that you actually deliver to customers for their use. The act of delivering it makes it such that they can use it and obtain value from it. The fact that one can demo it from their machine is of little consequence to a customer who needs a solution. I’ve seen many early stage companies and teams get in to the trap of not being able to kick the product out the door. The design and engineering teams keep futzing and tweaking it as they keep adding more and more features because it just isn’t “enough”. At some point you have to give birth to it, turn it loose on the world, and get real feedback from its real use.

Yes, that’s right–you have to deliver something and put it in the hands of customers to get meaningful feedback on it. Having focus groups and design partners are nice, Agile story demos during iterations are interesting, but until customers actually use your solution it’s all theory. If you think you have the prioritized list of features or the product roadmap laid out and you haven’t shipped or deployed yet you are working on fantasy; once it touches customers you’ll get more feedback than you could have imagined and much of it will rock your world—what you thought was the next most important thing to do or add is about to be laid aside… If you don’t deliver, you’ll never end up working on the right things… By trying to get it perfect out of the gate you may squander the opportunity to ever be able to add new features or capabilities as your customer’s patience expired waiting for “it” to arrive “someday”.

High Quality: What you deliver has to actually work and work well. It cannot be a Rube Goldberg device where customers have to memorize the exact sequences of steps to follow for any given task or activity to not have a defect pop up or to navigate around issues that get in their way. Quality also has to be measured in terms of the customer perception of quality and not some internal QA metrics that simply state “we’re busy” before we ship. Does it really matter if during
development 4,000 defects were found as opposed to 200? At the end of the day no—it is did the customer find any defects once deployed and, if so, how many and of what type? Did any of these cause them to lose data or prevent them from working? Did I cause any “self-inflicted gunshot wounds”–these being did I break something that use to work or did I cause performance degradation? Was User Acceptance Test truly a rubber stamp acceptance test of a holistic system or was it really a “let’s go find the defects” cycle where you used your users as your manual test team? Of my backlog, how much time do I have to spend fixing customer found defects vs. working on new capabilities that would further enrich their world?

Here’s a simple goal: Am I putting the Help Desk out of business? Yes, I said it. We, as software development teams keep the Help Desk in business. Why?!? That’s money that could be going to hire more of us propeller heads… We should be driving the calls to zero because our systems are so simple to use my mom can figure it out on her own (yes, I’m her help desk) and they just work so there is nothing to report as being wrong with it.

Solutions: It actually has to solve a problem. Wow, was that obvious or what? The code that you develop and deploy has to be a solution to a problem that the customer needs and wants solved. It doesn’t matter what you thought it should do or what problem it should solve; does it actually solve a real customer’s problem? If not, it was a wasted exercise of time, money, your energy, and your credibility. Do you know what success would look like from your customer’s point of view?
Failure? How would you measure either? What are your 2-3 Gee I’d Buy It Just For That! capabilities? If you cannot articulate them, the customer probably won’t be able to either…

Well that’s it for now. Thanks for getting to the bottom on this rather long post. Part 2 will be about the next part of my elevator speech: on time



Copyright 2011 Mark S Lawler.  All Rights Reserved.  If you’d like to link to it with a short abstract that’s okay.  Want to lift content?  Contact me first for permission.


From → Software

  1. I love this series! Thank you!!

  2. This is a great article. I love the Rube Goldberg reference- so damn true. Have you ever sat down with an analyst as they process a claim using F*cets? Holy crap– talk about a labyrinthine nightmare of sequences and tribal knowledge required to get through a screen- and onto the next and then..the next. I was at a tech conference last year where the vendor stated proudly that their oldest line of code was thirty years old. I nearly spit my coffee across the room. Anyway, I digress.

    Very well done– I bet our business customers would enjoy and appreciate this view into an IT delivery perspective.

  3. Hi Mark,

    Angie just sent this to me. Love the blog and will be sharing with the rest of my team!

Trackbacks & Pingbacks

  1. Key Metrics In Software Development That Matter « markslawler
  2. Improving Quality Up Front One Check-in / Build At A Time « markslawler
  3. Elevator Speech: Part 7 of 9: Have Fun… « markslawler
  4. Elevator Speech: Part 8 of 9: Being Ethical… « markslawler
  5. Elevator Speech: Part 9 of 9: While Transforming the Business… « markslawler

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: