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.

3 Replies to “My Minimum Viable PasswordRN Product”

  1. Pingback: This is beginning to feel a bit more real « Sheridan Programmers Guild

  2. Ted J

    I wonder how long your clinically situated nurses will have the freedom to choose whatever smartphone they want? I suspect there may come a time when the smartphone is like a stethescope, (or tricorder?) and be the core of the standard nurses kit, provided by the employer. It will have a variety of standard health care apps running, similar in function to the laptop/netbooks that are becoming very common in patients’ room, but in the smaller more portable form factor. I was joking recently with a cardiologist friend about combining an AED into a handheld/smartphone. She came up with the tricorder line.

  3. ag Post author

    I think you’ve got a couple of important points there.

    Everything about the app market is essentially ephemeral. The apps are relatively simple to develop (although not nearly so simple as it seems when you start out!) and are priced to be essentially disposable. Publishing an app that you expect someone to use day in and day out for a year or more is definitely working against the grain. As a ‘publisher’ it seems as if you have to think about some of what you produce almost as if it were more like a paperback book than like a traditional software product.

    From the point of view of being a software company, I think we have to stay open to OEMing any and all of our products into just the sort of “standard nurse’s kit” bundle that you describe. Frankly, that may be the only way to make much money off the technology we are developing.

    OTOH, those “standard kits” have been part of nurses training for years now. I think just about every nursing program mandates that the students buy and use a PDA fully loaded with reference material and various apps. But I hear that, when the nurses get out of training and into the real world, they don’t continue using those PDAs. Form factor may be an issue — so I expect that soon (already?) nursing schools may move from PDAs to the smaller smartphones (or, even better, the iPod Touch for which no data plan is required). And then the “standard kit” may become much more standard and more used.

    Or it could be that nurses, like other craftspeople, will prefer to assemble their own electronic toolkits, to be used alongside the mandated tools and processes. I certainly see that with programmers — no matter how much “standard kit” you are issued when you go to work in a new company/team, really good programmers also have a core of tools they’ve mastered that they continue to use to increase their own professional effectiveness.

    Thanks for reading and commenting!

Leave a Reply

Your email address will not be published. Required fields are marked *