Why Wearable Tech is Here to Stay

Lately the news has been buzzing with the latest in wearable devices.  Devices such as Google Glass, integrated watches by Samsung, Apple and other vendors, Vuzix Goggles (a Rochester, NY company) and Oculus Rift are starting to enter mainstream vocabulary.  Prototypes and beta software are starting to roll out and consumers and developers are getting to start to play with these devices hands on.  Some companies are even looking at creating heads up contact lenses!

This has all happened before of course - we've seen everything from surround vision helmets to heads up displays.  But never before has the actual technology really met the expectations of potential users -  whether it's limited use scenarios, bulky or cumbersome form factors, or poor integration and adoption by other platforms - many such ventures have started and fizzled.

So why is this time different?  Well there are a few reasons:

• Between advances in optics, small screen and flat panel displays, and miniaturization of essential components the visual aspect of the interfaces have gotten smaller, more useable, and more convenient.
• The ubiquity of extremely powerful cell phone devices means that processing and communications can be offloaded to that device, rather than needing to be integrated into the wearable platform.
• The improvement in wireless communications reduces  the size, and increases the range of components.
• People's addiction to ever-present ever-accessible media, through the use of always on and always connected internet devices has increased to the point where people crave the convenience of making that as quickly accessible as possible.
• Current interface methods through products like phones require hands-on interaction and attention distracting form factors.
• Voice recognition - by uploading to the cloud and analyzing in real time - has improved dramatically.
• Battery technology is improving dramatically making use of such devices more convenient.
• Movie media has started to prepare people for this reality.  We see fanciful interfaces in movies that mimic the interfaces that these devices give us - and we want them.

So are the new wearable devices perfect yet?  Not by any means.  While the hardware is starting to catch up there are software and social aspects that must be overcome.  How will having an always on and available camera change the way people interact?  If anything you say might be recorded and uploaded to the internet in real time - how will that change society?  There is significant social resistance to people using products like Glass and those issues will need to be addressed if it's to succeed.  And there are still plenty of technological issues to overcome.

I say to you though - these advances are inevitable.  Rather than railing against them your time might be better spent determining how to make best of use of them. Outside the personal use of such devices - the business uses are outstanding.  Imagine a tech having all his manuals and instructions available at will, and having both their hands free.  Imagine being able to shop or price compare by just looking at the bar code on a product.  Record a meeting for playback later rather than taking notes.  Video your professor in class.  Imagine your UPS or FEDEX person abandoning their scanner and just snapping a photo of the package barcode, and recording the GPS coordinates of the delivery.  These are all very real and very doable scenarios without any significant improvement in existing technology.

The advent of prescription wearable tech from Rochester Optical (another Rochester Company) for heads up display is particularly exciting - since the wearers of that tech are already used to having glasses, adding a heads up display is no leap for them - they are used to the idea.  Fashion designers have been pushing glasses as fashion accessories rather than for vision correction - paving the way for the addition of Google Glass and other displays into the world of non-prescription glass wearers.

So with wearable tech being inevitable - how are you planning to leverage that with your new products?  Is there a way you can enhance the use of your product with wearable tech?  Provide an alternate interface or display screen?  Integrate heads up vision?  Are you ready for this revolution and tapping it's potential fully?  OS-Cubed is - ask us how!

Why development isn't cheap....

As professional software developers with years of experience, our guys have become pretty good at estimating things.  You can't always be right, but if you have done a good job of choosing and limiting scope, and are developing in an agile environment estimating becomes more of an art and less of a science.  If you're in a business like ours, providing accurate estimates of how long something will take is key to success.  We want to build long term clients who will keep coming back for us for job after job - not one-shot projects where everyone leaves dissatisified.

The conundrum for a company like ours is though - we're too honest.  During the sales process we tell people how much it will really cost to do exactly what they want and the next thing you know they've moved on to others who promise to do it for less.  Do those "others" typically deliver it for less?  No.  We've followed up with some of these potential clients only to discover that they paid as much or more than we originally estimated, or ended up with a product that was less than what they wanted.  That's a sales process though that's doomed to failure - they've already spent more than they wanted to, exhausted their budget, and have soured on the whole "external development" concept.  "I told you so" may feel nice but it doesn't deliver successful products.

Now, with our ongoing clients we typically have an entirely different discussion.  Our clients tend to tell us up front - here is my budget, what can we do for that.  It's a different mindset - we KNOW we have more work than they can afford to do, but we want to get the best bang for the buck we have.

Now I promised in the title to talk about why development isn't cheap so let me give you a few anecdotes:

• For one client we're working with who has an existing codebase that's been worked on with 3 different programmers in the past, we've spent over 20 hours just getting a replica of their production environment working for doing testing.  This cost has to be built into the project even though it doesn't directly result in a product improvement
• For another client they want us to give them an estimate on changing a shopping cart.  But they don't have the source code for the compiled shopping cart module they're now using and can't understand why we can't just tell them how much a simple change will be.  We don't know because we can't see the code, or even tell exactly how the current shopping cart works.  Even if we had the code it would take at least 1/2 day just to digest the workflow and get the source code understandable - if the original programmer did a good job.
• Each of my programmers needs ongoing training, certification updates and time to research new solutions, fix old problems.  None of that is typically directly billable to a client.
• We need to pay for software and infrastructure for each programmer - test servers, source control systems, development licenses, backups, licenses, professional memberships - all paid for out of our pockets.
• Our programmers are salaried workers with benefits - so every hour they are here - and all the hours on vacation, regardless of whether they bill that hour, is a cost to the company.
• Our offices need power, lights, phone, mobile phone, fast internet service, etc.  Again - a cost that is built into the cost of our labor.
• The company pays their unemployment, disability, federal taxes, a portion of their medical coverage, etc.  All these add to the burdened rate
• Tech toys - you might think, why does that programmer need the latest iPhone?  Why do we have to have android, wp7, iphones and blackberries in our mobile phone stable?  Well the answer is - we have to test apps and mobile websites in these platforms to be sure they work.  All costly.

So the moral of the story is - if you're purchasing software development, consider all that you're buying.  Look at the level of experience and the satisfaction of the employees doing the work for you, and when you get several bids, remember - the lowest bid is frequently NOT the best deal when it comes to software development.

Being a program manager

One of the key things that every software development effort needs is an excellent program manager. That manager's key vision, leadership and customer advocacy drive success. In How to Be a Program Manager, author Joel Spolsky gives us some insight on combining agile programming and program management in a productive way. Since Joel worked on the team developing the next generation of Microsoft Excel, he's qualified to speak authoritatively about dividing up large projects into manageable bite-sized pieces. Like at OS-Cubed Joel believes that one program manager should be responsible for a team of up to 4 programmers, and that work should be divided up by functional area.

The most important part of Joel's article states that the program manager must be the customer advocate on the team. They must look at every interface from the customer (or end user's) point of view, and express that point of view to the programming team. Their job is to help the programming team design something that users will find easy to use and appealing. If users complain that the program doesn't work - it's not the programmers fault it's the program manager's fault.

I think this is an important point about program managers. Too often development teams focus on the program manager's job of coordinating resources and delivering on-time and in-budget without defining their visionary status.

Joel goes on to say that - despite agile programming pushing prototyping as a methodology, the program manager must write specs - detailed functional specs from the user's point of view - not the programmer's point of view. It's their job to advocate for the user and build an interface that is the best for them. I typically fill this role within OS-Cubed, Inc. I have just enough programming and platform knowledge to be dangerous, but not enough to be so buried in it that it's all I think about. I would go on to state that a good program manager probably has a high "DI" in the DISC test and a low "C". I will talk more about DISC and how it integrates into a programming team later.

The program manager should not however, be the person writing up the actual specifications for how the product should be developed (that responsibility is the programming team lead's job), nor should the programmers report the the program manager because that would allow the program manager's ideas to run roughshod over the programmer's. This needs to be a negotiation between what is optimal and what is possible and both the user's and programmer's needs are taken into account.

Agile programming is typically about fast turnaround and constant customer approval. So the program manager must stay ahead of this curve, constantly re-examining the impact that feature and user interface changes have on the full vision. Sometimes it will be their job to control the scope of the project and to do that they need to retain and update the vision as it changes.

Joel's article is a great read, and I highly recommend both the blog post itself, and the links he offers for help and assistance.

End users are not stupid....

I read a great post today thanks to Larissa Reynolds, a good friend down in the great state of Texas. The post was written on http://cuhype.com and entitled "Hello, Our members are Morons". The author identified only as "Tony" was discussing how when he would pitch a Credit Union (his marketing specialty area) on a new marketing idea they'd frequently shoot it down saying that their members "wouldn't get it". He went on to explain why this was really a fallacy, and that with the right message and the right delivery you can hook a lot of people you wouldn't just assume would get it. Management's assumption seemed to be that it was ok for THEM but that their MEMBERS wouldn't get it, understand it, or be able to do it. This sort of belies the fact that most of THEM are members of their own credit union :)

I was reminded of a particular phrase that I usually use with my entrepreneurs when they come to me with their ideas. Take Knowledge Athletes for instance. They come to me with a great educational idea and I have said more times than once "you guys are the education experts - I'm just the software developer". If they think it's a great idea - it's worth a try.

Which is not to say I don't push back sometimes for a simpler interface. It's my job to advise people on the best way to implement their idea so that it can be enjoyed by the widest audience. But we must always be careful not to dumb something down to the point of no returns. It's ok for our users to have a brain - and to need it to accomplish a task.

We were pleasantly suprised for instance how quickly kids were able to pick up the Kajour application and run with it - sometimes despite bugs and growing pains caused by it only being a demo system. We found we could make the interface much more complicated than we originally anticipated and it would still work great for the kids. They were USED to figuring out complex interfaces. They'd grown up in the world of Facebook, MySpace, YouTube, and other tools and didn't mind poking around in menus or selecting icons until they could figure out what they needed.

So the all around summary - don't assume your users can't use a sophisticated interface. Don't underestimate their ability to "get it".

An agile programmer team room

I've been reading and admiring the quick article on http://www.scissor.com/ about building an Agile Programming team room. While we have many of the same elements in our development environment there are many ideas here that I'd love to steal er borrow :)

I was surprised by how much their offices look like ours. We also have an open floor plan, tons of natural light, dual monitors at every workdesk, lots of available whiteboard space. One of the things I loved about their space is the overall storyboard with colored cards, and the weekly iteration rollover plan. Very nicely laid out.

Agile or XP is a methodology frequently used in early stage (and some late state) startups to rollout product effectively, iteratively, and with stable solid builds. The idea is to rollout stable usable versions of the application almost weekly. OS-Cubed's methodology definitely adopts many of the great ideas of XP, but we're always learning new things about how best to develop software.

I'm going to challenge my programming team to take a look at this and see what elements they feel might help them keep on track and develop better software. Thanks to scissors.com William Pietri for revealing some of their "inner geek"...

Followup on usability testing... and a bit of a break

I'll be taking a bit of a break for a week as I take some time to relax, but in the meantime you might want to take a gander over at Lightspeed Venture Partner's blog. They have a great followup to their recent usability testing article which I commented on here.

In this post they go into depth on what sorts of testing are appropriate at various levels of development. Most of our work for entrepreneurs has focused on the Ideation phase of development, where LSVP recommends that you explore new ideas and opportunities, take the founders vision and add in the background developed during initial testing. Specifically Knowledge Athletes (aka KA one of our most successful clients - our first) has performed the following types of testing in their product roll out from LSVP's list:

• Ethnographic field studies (KA's "in school trials")
• Focus groups (KA has focus groups consisting of high school students at all levels, college students and corporate clients)
• Diary studies (the unique nature of KA's product is that it IS a diary so users can comment and track their usage of the product IN the product itself)
• Surveys (So far online user surveys have created a number of interesting new ideas for the product)
• Data mining (As KA has created user experiences TONS of data is now available on how the product is used and when it has been successful. This data is leading not only to new development ideas, but also paradigm shifts in teaching methods)

Th original paper on this topic by Christian Rohrer of xdstrategy.com has a great chart that shows where studies work best and compares data source vs approach vs context of use. You can learn more about usability testing at this University of Texas site.

Alternatively Jakob Nielsen's book on usability testing (linked below) is widely regarded as being one of the best in the industry.

Analyzing software features

In my post on scope I discussed the idea of limiting scope - both to budget and to goals. Brad Feld in this post, mentioned an interesting methodology, which quantifies the method we've used in our projects in a neat and tidy way. Since we work with early seed companies and startups in the Family, Friends and Acquaintances funding mode, we are constantly working to see what features we can build into a project for a small dollar budget. Obviously we need to leave some features out, but how best to decide?

Brad neatly summarized the decision as chartable on 2 axis. Along one axis is appearance vs substance (though I prefer the term functionality), and along the other axis is what users say they want vs whether they are willing to pay for that feature.

I would add a 3rd dimension - what the cost to code, test, implement and train are vs the speed at which the new feature can earn back it's investment. I know this is a purely ROI sort of view of the data, but it lets you see whether it's really worth it to put limited dollars into a particular feature. Perhaps in Brad's discussion they were talking about once there is Venture money already in the development and it's more a choice based on having enough money to do everything but not wanting to overburden the product with features. In our world though it's literally what can we afford. If Feature A has strong functionality, and users are willing to pay for it, but it would cost 2x as much as we have in the budget for development - then trying to build it won't help anyone until we get more funding.

In any case, it's an interesting thought exercise, and one that each entrepreneur should go through as they try to narrow down their feature set and build their demos and proofs of concepts. Take each feature and chart it three dimensionally. This will help you visualize your feature set, and decide which features to build, and which to build first.

How to limit scope to funding

One of the biggest challenges in your early stage development will be limiting the scope of your project to the budget you have. In this stage you're using your money, your friends, your acquaintences, or maybe you have a first round SBIR grant and have a few 10's of thousands to invest. While you may be able to build some types of software with a budget that size - realistically to build something scalable you should be thinking bigger in terms of budget.

As we pointed out in our second post, when entrepreneurs come to us and say "I have $10,000" and in the same breath they say "and I want to develop something just like ebay only better" we just cringe. We know that there's going to need to be some education going on before we get to someplace that will satisfy their need to get real funding to grow their concept, within the budget they have.

Like it or not, the days of having programmers around who will sack out with friends, eat ramen noodles and put in 80 hour weeks for no pay and the promise of "stock options" at some unknown later date is just plain gone. Programmers have to eat, and at least for the moment demand for developers is quite high - so they can make money doing other things. Sure you may find one or two passionate gurus, but building a team is a different matter. After programmers got burned in the 2001-2003 dot com implosion, most want a real salary.

So when someone has a giant bag full of cool tricks that they believe will revolutionize the web universe we usually work closely with them to try to identify the core unique part of their business model that makes them special. Is it some trick or gimmick, a unique view on a market, an interesting model for monetization, a new approach to real estate, or a great educational paradigm? Then we try to work out a budget for a limited demo version of that core idea that can be used to attract new investors, test the idea out on real users, and provide a demo portal for the entrepreneur to use.

We just keep dumping features out of the product bag until we have it's core at our heart. We build that core, and then we add the features into it incrementally as funding becomes available. Got round one for $50K? Ok we'll build out the base site and the most interesting and unique part of your app. Got SBIR Round 2 for $100K? Perfect, we'll rebuild the core to support more users or traffic and we'll add some additional features. To make that work of course and move on to each round, the software has to be built to meet the milestone requirements set forth in the grant or by the funders. We help achieve that by working closely on the proposals and presentations with you to be sure you set expectations that can be met within budget.

That's not all there is to it, but that's the core. We'll build the features out in a later post :)

Usability testing in entrepreneurial software

Jeremy Liew of Lightspeed Venture Partners has an excellent blog post on Usability Testing and how it applies to building entrepreneurial software. In his post he mentions that it's not just about rapid prototyping and turnaround (which he approves of) but also says that at some point you have to step back and do surveys, and psychological profiles of users and see exactly HOW they used the site. This is a critical step in building software, and obviously (since Jeremy commented on it) important to getting venture funding as well.

At OS-Cubed, we believe that usability testing should be scoped into the project itself, and the amount invested in it should be scaled according to the entrepreneur's budget, but it should be conducted throughout the development process as you're building your demo or proof of concept and rolling out your RAD prototype. In the early stages usability testing does not need to be either expensive or costly. You can do much of the testing yourself with the demo as it's rolled out. Noah Kagan of Mint lays out the steps for you in his excellent post. They involve basically: determining what to test, finding a representative user base, and then testing by observing. Noah recommends using Webex products, so far we've been lucky enough to have user bases that are representative right here in Rochester.

As Noah points out - doing this can be frustrating for the observer. The observer needs to sit back and let the user do it - without intervening or showing them how.

In our experience most of the user testing we've done with KaJour our product for Knowledge Athletes has shown up issues in the scalability section - which you'd expect in demo software. We'd actually anticipated these issues but didn't have the budget to build production level. We consciously chose with the entrepreneur to build more features, rather than make the features we had more robust. The users have also come up with unique and interesting ways of using the product that we didn't anticipate and neither did the Knowledge Athletes staff. Through our user testing we've found new markets, new ways of thinking about what we're doing and developed new teaching paradigms for the community we're serving (at the moment mostly high school and college students with this product).

Although Jeremy points out the obvious benefits of using usability testing to be sure your software is stable and simple to use, he doesn't mention that really listening to your users can allow you to create new and better uses for your software, and take your product in an entirely new direction. To do that you need to truly listen to your users and find out what it is they need - what pain you are solving - and how you could do it better.

What is the typical funding cycle of a startup software entrepreneur?

More often than not when I get a question from a budding software entrepreneur the question is about funding: How to get it? What are the next steps? How can I be sure I'm getting the best dollar for my investment?

At OS-Cubed we only work with companies that have at least some funding. Not necessarily angel or venture funding - but FFA (Friends, Family or Acquaintences), self funded bootstraps, SBIR or STTR grant funded, or some other sort of funding mechanism. In today's Web 2.0 world, most of the "big funders" - the angels or ventures of the world - expect that you will have some "skin in the game" and already spent some dollars or sweat equity building the demo or proof of concept of your site.

Web entrepreneur and funding expert Brad Feld says that a typical Venture or Angel firm might see 2000 applications for funding in a year, and 15-25% of those will be for software development projects. If we take the 20% median that means 400 of those applications are for software projects. He also said that of those 400, 1/2 of them had already spent between $25,000 and $1M on building a demo or proof of concept for their site - before they applied for funding! That's 200 demos or proofs of concept per year - all funded by FFA, Grant or bootstrap dollars - and that's just for one firm.

So how does that funding actually work? We've worked with a number of entrepreneurs and here are a few models that can be successful:

• Grant funding - public or private grants from interested parties that can assist you in startup. The most obvious of these is SBIR, but there are others.
• Bootstrap funding - create a small app using FFA/Self funding, convince people to use it, use the revenue from the small app to pour back into the app itself, convince more people to invest, and build it bigger and bigger until you have a provable model that you can get funded for.
• Sweat equity - give yourself and/or others a portion of your equity to build the first versions for free. Use that result to apply for other funding sources.

Each of these has it's upsides and downsides. We'll address each one in a future post.

How important is a proof of concept?

So just how important IS a working proof of concept to funders? Can't you just drop your idea on an investor and sell them on it - then get funding to build it? Well yes, you can -if you have a history of building software companies before and succeeding, or more rarely if you have an idea that's just so mind boggling that the Angels and Ventures just jump all over it. Pretty rare though. Most serial entrepreneurs (whether they have a solid record of success or even a spotty one) have a leg up on the rest of us when it comes to getting funding for an idea before they build it.

But let's face it - those folks already ran the funding gauntlet and convinced someone to lay down cash for them. For the folks that have a great idea but have never implemented before they have to "prove their creds". They have to show the potential funder that they have the ability to deliver on the promise.

One of the best ways to do this is to bootstrap a demo or proof-of-concept so that you can show your potential funders real numbers and testimonials, with real people using your software. A great demo will show investors that it's a cool idea that can generate revenue. The characteristics that make a great demo are as follows (and I'm always open to ideas about what else may make a great demo):

• You must limit the scope of the demo to what you can afford. Many entrepreneurs try to jam as many features as they can into their demos - and none of the features end up working well because they really need the $$ the Angel or Venture will invest to build production level, fully featured software. In this case KISS is fine (Keep it Simple Silly).


• You want to build something that has limited scalability (might service only a small audience), but that still shows the core feature(s) of your product and how it delivers revenue. You may end up tossing out vast quantities of what you develop when you move to building production software. THAT'S OK. What you're building in this round is enough of a system to convince an investor to give you the $$ you need to make the REAL software.


• It's extremely difficult to create fully scalable business software on an FFA funding (Friends, Family and Acquaintances) budget. Building scalable software is not easy, or cheap. It takes a lot of resources, good management and a solid team to build, support and improve software that is scalable and stable. I love when people point me at a site that has had millions of dollars invested in it and say "I want to build something just like that only better" and I have $10,000 to do it. It's just not going to happen. Build something realistic.


• Yes delivering revenue is important - even if that revenue is small. If you're building something based on an advertising click through model - having users click through in your demo is as important as whatever cool features you've designed to get them there in the first place. If you can show your funders that you have the ability to deliver not only on the the cool feature but on the revenue generation you'll be that much further along towards proving your model. You don't have to generate revenue but you must prove you COULD generate revenue and show how you will do so.


• Although you want the demo to be as stable as possible, it's OK for it to have a wart here or there, or an unimplemented feature. You can still build a demo that proves your concept without spending the money to make it fully stable and scalable. Limit your target audience to one browser, a limited number of users, single language, one checkout system, etc. Be sure the functions within those limitations work well, and be clear about them if presenting. Don't promise Firefox compatibility if you haven't tested it and don't be shy about saying "At this time the demo only supports [Browser X], but once we're funded we'll expand support to browsers y and z."


• Take the feedback of your beta testers seriously. If they never use a function that you spent a lot of time developing - consider throwing it out. It's never good to clutter up an app with features that users don't want or need. You don't have to run out and fix or change things in this round, but preserve all those comments and criticisms and be prepared to address them in future rounds or plans.


• Don't forget about monetization. To ultimately succeed in the venture world you need a business model that supports 5x growth in initial investment. If your initial tests don't prove that out - you might be in the wrong business. Better to find that out now.


• Build incrementally, and do it within the scope of the funding you definitely have - not the funding you hope to get. Release early and often.

Initial proof-of-concept and demo software is frequently created with FFA (Friends, Family and Acquaintance) or grant money. As such, it's typically limited in quantity, may be only available on a cycle or with a specific deliverable, and - especially with the FFA money - it can be painful to say you spent it on development and then never moved on to the next step where they might get their investment back. It's incumbent upon an entrepreneur to spend that money as productively as possible to ensure success.