Home » Posts » Software Engineering » Avoiding Cloud Obscurity Helps You Build Better Products

Avoiding Cloud Obscurity Helps You Build Better Products


Obscurity is something you want to avoid at all costs when it comes to product definition. It will simply kill your project regardless if you’re a well funded startup or just trying to bootstrap one.

I was reminded of this a few months ago when a potential client looking for developers to add functionality to their content delivery network, asked me how my product was related to a CDN.

I’m sure that the explanation of the distributed CMS used to span multiple networks; automatically balancing keyword phrases and authority to produce optimal search engine rankings made me sound like a jabbering idiot.  Usually the more complex a product is, the more obscure it is when you try to describe it.

Needless to say, I did not get the contract which is sad because I thought I could have added significant value to their product given my background.

However, my failure was to recognize that my product was of no value to anyone but to me. It added no value to visitors in the domain and eventually the over optimized pages produced by the CMS were dropped from Google’s SERPS.  Having a succinct product definition surely would have helped with the traction and out of the bootstrap and funding stage at least to the point until Google changed their algorithm.  Or would it?

What Makes a Product Viable?

The inability to articulate an overly complicated product is probably the signature that you are on the wrong track. For any product you should be able to clearly identify and answer these questions:

  1. Who are the customers?
  2. How many customers are there?
  3. What does the product solve?
  4. Does the product bring value to table?
  5. How much is the customer willing to pay for it?

Add these factors up and you have a viable product. Of course, if you have enough customers paying for your product, you may have a profitable and sustainable project which your startup can build.

In 1848, Oliver Wendell Homes published Lord of All Being a poem about man’s relationship with God. I particularly like this stanza and how similar it is when it comes to our relationship with our customers:

Our midnight is Thy smile withdrawn;
Our noontide is Thy gracious dawn;
Our rainbow arch, Thy mercy’s sign;
All, save the clouds of sin, are Thine.

In my case, “the clouds of sin” were mine.  I had one internal customer and no external customers willing to pay for the product.  Basically my great idea to produce a distributed CMS failed because it was not profitable and sustainable.

The trick is to find paying customers that have a problem which you can build the product that solves the problem.  There’s a subtle difference where you don’t want to build a solution to a problem and later find customers; you want to find customers first then build and sell the solution.

Adding Business Value

In Agile you’re always writing user stores which adds value for customer.  One of the best examples of this is found here, but in general you want to write stories in one of two ways:

  • As a <User Role> I want <Functionality> so that <Business Value>.
  • In order to <Business Value> as a <User Role> I want <Functionality>.

The common theme here is that you are going to implement something which adds value to the customer.

Conceptual Drawing of QR Code SaaS App

The problem is that we tend to come up with ideas first thinking that it will add value, then try to locate customers to sell the idea to.

Does an Idea Add Business Value?

Only if you can express it in product viability terms.

We all come up great ideas everyday.  Most of my ideas come to me in the shower or while taking a walk to break the days’ fatigue. But I’m able to retain and capture ideas out of the shower because I’m carrying my smart phone.  A quick entry in Evernote and I’m able to work out if the idea is viable at a later time.

One day I was out walking the neighborhood and saw a home for sale which I really liked. Usually the Realtor puts out flyers about the home next to the “for sale” sign, but there were none left.

I was about to call the listing agent for more information when the thought of having a QR code printed on the flyer box or even stuck on the sign would have helped immensely.  All I would have to do is scan the code into the phone and visit the listing page on their site.

I sketched the concept and call my friend Thomas Mayhew who sells homes in the Pasco, WA area to see if the idea had any merit.

I’m certain that I started describing the SaaS App right off the top of my head instead of explaining the business values such as:

  • As a buyer, I want more information on the home, so I can see if this is the one I want to purchase.
  • As a agent, I want to provide home information, so I can sell more homes.
  • In order to sell my house as a FSBO (owner), I want to list it on the internet, etc.,

so I pretty much got “crickets” in response.

Perhaps my mention of this is a “free service” didn’t help and basically reduced any possibility of turning a profit making the project DOA if it is bootstrapped.

Does the Idea Solve a Problem?

It really comes down to defining a product which the customer wants and is will to pay for.  Stating it in an obscure description such as “the service quickly brings property information to a buyer with a smart phone and allows the buyer to accurately contact the listing agent as a potential client” doesn’t cut it.

But if the problem/solution was stated “the buyer will thank you for being so considerate about not wasting his time by making it efficient to find the property information, thus, it is a no-brainer he becomes your client.”  Or, how about “you provide on-the-spot accurate property information to pre-screen potential buyers so you don’t waste you or your client’s time driving them around to see the listing.”

I think the later less obscure definitions solve a problem which a customer will buy since it saves them time and helps them get more clients.

Better Definitions Produce Better Products

When your build your product, make sure the definition is crystal clear on what problem it will solve for your customer. Make sure it will add value.  If the customer recognizes value in the product, surely it become easier to sell and justify to them.  As Holmes may have put it, we do not want our customers “smile withdrawn” otherwise our product will fail.

Loading Disqus Comments ...