Execution Risk

Here’s a textbook topic that is top of mind this week at BeHome247, a company where I’m an advisor.  This particular company is installing pilots of a home automation system in conjunction with two strategic partners.  It’s a mesh network arrangement using a gateway connected to the Internet router so that everything from locks to thermostats to lights to cameras can be controlled remotely via the smart phone or tablet of your choosing.  Our company has determined the overall topology using industry standard communications protocols and developed all the mobile UI/UX components.  However, we depend on integration with the API’s of one partner’s back-end systems, on the firmware in the smart components, and on some additional 3^rd-party code in the overall software stack.

This all adds up to a lot of code that must work in concert to function as advertised.  And a lot of it is new enough to have plenty of virgin bugs yet to be discovered and fixed.  We can deal with that, even though bugs often manifest themselves in places far removed from the actual problem source.  If you’ve ever tried to find the origin of a leak in the roof of your home, you know what I’m talking about.  Water can find strange pathways to your ceiling from somewhere on the other end of the house.  However, since our software is what is visible to the user, we “own” all the problems and have to chase them to happy resolutions.

The challenge is magnified when hardware is involved and when the pilots are in far flung locations.  We’re finding a number of cases where the Internet service is down, so there’s a day or more lost waiting on a truck roll from the cable company and then a return visit by our installers.  In a fair number of cases that involve thermostats, the wiring suffices for normal usage but isn’t up to standard specs for our needs.  There’s another truck roll by the HVAC installer and another return visit by our team.  Then we get to the subtleties of having bad information about the exact finish on a lock, the type of handle, which way it’s oriented, and other features.   That’s a trip to Home Depot at least or sometimes a direct order from the lock distributor.  You get the picture here, perhaps.  What should be a pop in and out 2-hour installation may take several days and several visits.  We’re making this all work to the satisfaction of the pilot customers, but for sure this learning experience will influence how we administer and how much we charge for live installations during our full rollout.

Then there’s the problem of user behavior.  We’ve had one case where the home occupant propped the door open using the deadbolt while walking the dog.  That did just enough bending on the striker plate to keep the bolt from electronically extending into the receiver under normal usage.  That was another truck roll, and another bit of detective work to be done.  I am personally very good at breaking software during development with unorthodox uses, but any product that is exposed to the full gamut of human ingenuity is going to meet with some such surprises.  To this day I even remember when a customer at one of my early companies was told to insert a floppy disc and shut the door.  We could hear the person walking across the room and shutting the door to the office, but leaving the disc drive door open.   We obviously weren’t literal enough in our instructions.

I read with some interest that Mobiplug, one of the recent TechStars Boulder class graduates, is described exactly like the company I’m referencing in this post, using open source technology to bring a low cost “Internet of Things” to home automation.  The founder of our company had that same vision 4 years ago, and as I see that philosophy put to the test in actual field usage, and when I’m hearing no pushback on pricing, I’m thinking the overall ecosystem costs may keep this technology at what I call the BMW price level and above.  No two homes are built quite the same; even in large tract developments it’s still an artisanal process, and not all builders and their workers are well trained artisans.  There will always be surprises in this type of market, and for a business to be profitable its pricing will have to be high enough to cover those surprises.  But, that said, it’s still a very big market and a real opportunity, one that has the attention of any provider of a “wire to the home.”  Our team knows how to do pilots and learn from them, which is why we do them in the first place.   And, if nothing else, the findings of the last few weeks have validated the wisdom of that approach.

If you are working on even a simple app that relies on Facebook, for example, or some API’s, your degree of difficulty may be less than we’ve seen with a mixture of consumer hardware and software, but you need to remain vigilant with respect to the integrity of your entire ecosystem.  You’re always subject to bugs not of your making, and, even worse — features, rules and policy changes that might shred your product roadmap. Not many of us will achieve Apple’s level of control over an entire ecosystem, but even in their case myriad countries where they manufacture and sell can cause them plenty of problems.  The bottom line, don’t get too cozy with customer acquisition and retention successes alone, you’ll get thrown some serious curve balls by your customers, vendors, and partners somewhere along the way.  Just be ready to deal with them and treat them as part of the natural rhythm of the technology business.

Thanks to our always reliable sponsors MailChimp and TriNet!

<Wikipedia image of Robespierre facing a more serious form of execution risk>

About Ben Dyer

Ben J. Dyer is the president of TechDrawl LLC, which produces the blog TechDrawl promoting technology entrepreneurship across the South. He and his partners also consult with early-stage companies with respect to business strategy, product development and capital acquisition.