Icons and software and phones, oh my!

I’ve fallen down on my commitment (to myself) to post about once a week.  But better to have a busy and productive three weeks and not quite get them narrated than to write a lot and get little done.

Just before the middle of June, I contacted a local graphic designer, Michelle Miller of Sheridan Design to get the ball rolling on some icons for the phone apps and web sites.  However, Michelle isn’t really a “get the ball rolling” sort of person; she’s much more of the “git’er done” type.  With a flurry of emails back and forth and in less than five days start to finish,  I suddenly had a whole suite of logos  for the ChecklistRN website, the PasswordRN phone apps, and the CalculatorRN webapp that Hokan is developing.  I’m delighted with the results and the work fit inside the budget numbers I initially laid out for Michelle.  I’d like to think that the fact that I had a very clear idea of what I needed and am a decisive and appreciative customer had something to do with the speed of the project.  But, frankly, as far as I can tell, Michelle is just plain good at what she does.  You can see one example of her work in action at the top of the ChecklistRN blog.

About a week ago, Sara delivered her first batch of Android enhancements, fleshing out the security features for the master password and the system passwords.  I haven’t had much chance to test them yet.  But, this afternoon, our Android Developer Phone walked in the door — so I think I’ll combine testing her new features with seeing my own code run on a real phone for the first time.  That experience will be both cool and humbling (UI not being my forte).

(For anyone paying attention to the details, I did get Mercurial and BitBucket working after my last post although I temporarily abandoned the Eclipse plugin and went to TortoiseHG which worked out of the box and very intuitively.  So the Android sources ARE checked in to a central repository although I’ve just been getting zip files from Sara, merging her code with my own locally,  and checking in from here.  We aren’t quite up to speed on the D word in Distributed Version Control yet :-}.  But the BitBucket wiki that comes with my account has already proved handy for documenting some process things for Sara, so I’m quite pleased with that. )

The word from Laramie on the iPhone version of PasswordRN is also all positive; I’m supposed to see an initial version running on an iPod near me within the week.  It will be an incredible experience to sit at a table with the Android phone on one side and the iPod on the other and walk the same app through its paces on both.

Speaking of which, Mark agreed to a) help with some competitive analysis and b) get up to sped to do QA for our own apps.  He’s been running one of the popular iThingy password managers, which shall remain nameless for the moment,  and HE HATES IT.  Not the app, itself, so much, although he has found some quirky things about it.  But the whole iPod app-running experience.  The screen is small.  The touch screen is, in his words, “just not made for a hand with calluses on it.”  It’s not as if he has huge hands but he finds typing on the virtual keyboard is a painstaking, error prone experience.  We’ve bought him a stylus and we’ll see if that helps.  Plus, more instructive for me, there are some definite usability features that seem obvious to him — features for the over-forty crowd but also frankly for anyone in poor light or under stressful conditions.  I fear that simplicity and BIG FONTS may not be very Apple-UI-guidelines-compliant but I think they could be very much appreciated by folks trying to use a phone to help them get real work done.

My Minimum Viable PasswordRN Product

As a programmer, I try to follow the tenets of Agile Development, at least as far as I can when I’m often working freelance within groups of other developers who are following variations on the more traditional waterfall method.  (This is a case where forgiveness being easier to get than permission is critical.  My big customers seem to have become rather accustomed to the fact that, if they ask me to write the formal specification and then the code, the spec never quite gets done but they do end up with satisfactory, working software.  So now they pretty much just ask someone else to be in charge of the spec.)

One of the hardest and most important of these Agile principles is:  “Simplicity – the art of maximizing the amount of work not done – is essential.”  Although, day to day, I usually work with the corollary that reads:  “Start with the simplest thing that can possibly work.”  You can deliver simple functionality sooner and get feedback from others that you are on the right track (or not).  Plus it is:

  • easier to fix simple code if it is broken,
  • easier to enhance simple code than to graft functionality onto something complex,
  • remarkably difficult to remove excess functionality from code after you’ve once got the whole thing working, and
  • much, much easier for users to react and tell you what you did wrong or what is missing than it is to tell you what they really need up front, with nothing in front of them.

The software startup industry (and it has become an industry – there are a huge number of websites, book authors, and consultant gurus now making a living catering to the even larger number of people who want to build the Next Killer App) has their own corollary:  Start by producing the Minimum Viable Product.

I’ve been a bit doubtful of this MVP concept because, frankly, in the wrong hands it’s nothing more than a fancy name for the smoke-and-mirrors products that have always created a credibility problem for our industry.  I don’t buy it that a honeypot web site, with little content and no functionality, whose only purpose is to measure traffic driven to it via AdWords can be called a ‘product’ no matter how many adjectives precede the word.

On the other hand, I’m extremely attracted to what I think is the original MVP definition:   “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”    Having once worked on a software product that famously consumed several dozen person-years of development, marketing, and sales effort over the course of two calendar years and NEVER SOLD A SINGLE COPY, I understand the value of ‘validated learning about customers’ with my gut, not just my head.

And I can see where there’s no reason the MVP has to be, necessarily, even a pale shadow of what you guess the finished product will be.  After all, the point isn’t to prove you can build what you can imagine, although with any luck that will get to be important, too.  It is to see where your definition of the problem, your understanding of your potential customers, and your product concept, match reality, or don’t, as early as you can, and then make adjustments.

So, briefly, here’s the background for my PasswordRN product concept:

My definition of the problem comes directly from my best friend Denise, who recently became a Registered Nurse.  She now works on the maternity ward in a teaching hospital that is a magnet for difficult cases in its region.  At least a few times each shift, she has to log in to standalone medical devices that now require authentication before they can be used.  Each device has its own password rules and schedule for re-setting passwords.  Sometimes she needs to log in fast because, frankly, lives are at stake (usually at least two lives in her particular line of work).  She finds remembering the passwords to be an annoying, frustrating task and would like to have a safer way to record them than a notebook she carries in her pocket.

My understanding of my potential customers is my weakest link.  I know there are about 3 million RNs in the US, the majority are female, and over half of them are over 50.  I’ve done enough phone research to find out that not all nurses have Denise’s problem – it may be an issue only for RNs (not CNAs and maybe not LPNs) and you have to be working in a clinical setting not, say, in a family doctor’s office.  But I’ve found other nurses who DO have the same issue, exactly.  I know these women work long shifts under great stress.  The good news:  They carry cell phones with them when they work. The bad news:  I’m certain most of those cell phones aren’t smartphones yet and I have no expectation that nurses will be attracted to any one smartphone platform more than another.  Also good news:  I’m willing to go out on a limb and predict that most of these women do NOT consider surfing the web for hours on end looking for the coolest new software as their idea of a great good time.

My product concept is to produce a simple ‘password keeper’ phone app that is optimized for use in a clinical setting and that intentionally doesn’t have many of the features that a traditional password keeper app is supposed to have.  By producing a targeted feature set and backing it up with targeted marketing, I hope to attract buyers who might not bother to go looking for a generic solution in the noisy phone app marketplaces or who would be turned off by the over-featured versions currently available.  (I really like the idea of competing not on price, since phone apps are all disposably cheap anyway, but on being the simplest and therefore saving busy people the TIME that is more precious to them than money.)

My Minimum Viable Product isn’t a phone app.  I have versions of PasswordRN (for the iPhone and the Android) currently under development but there is, frankly, no feature set smaller than the one I imagine for my initial version.  So my MVP is ‘just’ a website but a website that delivers some value to others while, I hope, delivering huge learning opportunities to me.  I envision a series of short articles such as:

  • What’s a smartphone and how is it different than the phone in your pocket today?
  • Don’t let anyone give you a smartphone – till you decide you are ready for it.
  • Data plans – “ouch” or “wow”?

I’d also like to make a directory of, and write some reviews for, the current password keeper apps available today.  I find the app marketplaces noisy, confusing, and hard to navigate.  Why not, while I do some necessary competitive research, provide some timesaving pointers for others at the same time?  If I can find a ‘simplest-one-for-now’ competitor, I may even recommend it.  And if, in the meantime, I can learn enough about search engine optimization and, maybe, AdWords to drive some traffic to my site, I may be able to do the important learning:  find out if there actually are enough nurses out there who share Denise’s problem to make my product idea viable or, if not, what DO they need?

What I always tell people, when I describe what it is like to work as a programmer, is that “it’s like having a license to learn for a living.”  What I like about this approach to an MVP, is that it’s like giving myself a free-pass to learn an enormous amount while also building my product and my company.