The first PHR Patent Troll?

Posted on by

The following just came across my Google Alerts:Healthcare Analyst Values MMRGlobal Patents at $300-800 Million. This is scary. I’ve seen this company for years; they were one of the pack trying to build personal health records in the mid-2000s, and from what I’ve seen there is nothing in their historic offering that was particularly innovative – except that unlike most of the others running around at the time, they appear to have had some budget to file some patents, and they have now commenced shaking other people down.

Now, I haven’t done a very complete review of their patent holdings, and they may well have some highly innovative, original work there that took a substantial investment to develop and realize. But that’s not the trend, and I’m very concerned that this could be problematic for a lot of small innovators in the personal and clinical health records markets. Software patents have become a real problem across a variety of domains, but so far HIT seems to have avoided the worst of it. I suspect that this is in part because of industry’s long history – most of the core capabilities were introduced long enough ago that any patents would have expired. There’s a ton of prior art: you can track a lot of personal health monitoring to 1994′s Guardian Angel Manifesto. But that’s expensive to litigate when the trolls come out from under the bridge.

As it stands, I’m looking for defensive patent structures for my own start-up so that we have some chits to trade if someone comes knocking. And that’s a shame – I have better things to do with my time.

Building a Sales Team

Posted on by

Just read a nice summary from OpenView on hiring your first sales manager. This is, far and away, one of the most daunting things that any technically minded startup CEO faces. If you come from an engineering or science background, it’s easy to think of the sales team as, if not actually an enemy, as something a little bit alien. I know a lot of engineers who simply don’t get on people in sales – they regard them either as ineffective suit-fillers who can’t do “work that matters” or as the latest embodiment of the obnoxious popular kid from high school.

Some companies try to get around this by making sales people out of people who aren’t naturally sales people. In the Healthcare IT space, that’s often former nurses or physicians who want a career change. In software, it’s often software engineers. There’s potential in all three groups, but it takes a certain type.

If all goes well, I’ll be going through this process again in the near future. If so, I’ll post what I learn.

 

 

Learning to Code

Posted on by

Knowing how to code is a really useful skill for anybody in business. For an entrepreneur, it means you can validate your high-tech startup idea without having to out and recruit a CTO or spend a lot of money on an external software development shop. But even if you’re running a pizza place, a little bit of coding experience can save you a lot of time when you’re playing with Excel spreadsheets late at night trying to figure out how much money all that fancy pepperoni is costing you.  Most people are in the middle. I have a lot of friends who went into management consulting – the ones who know how to write little bits of software to help them do their jobs tend to get a lot more sleep at night.

The other reason to learn programming – even a little bit of programming – is that it makes the whole process of interacting with technology a lot less scary. Computers are black boxes, and people don’t trust black boxes.

So I thought CodeAcademy was pretty cool. It’s a web site that takes you through some simple programming exercises in JavaScript, which is one of the most common programming languages on the web. In half an hour you can go from no experience at all to writing simple programs. They don’t do that much, and to solve real problems you’ll have to do more. But it’s a nice way to start out – and even if the student doesn’t go any further they’ll benefit from a more visceral understanding of how computers work. In the best case, it will teach them to recognize the kinds of patterns that can be solved with a little code.

Having written that, I suppose I should consider the opposite extreme. Just because you can write simple programs after half an hour of interactive lessons doesn’t mean that software development is either easy or low-value. It’s not. A top-tier software engineer took thousands of hours to get that way.

What’s Worth Copying: Junk Removal

Posted on by

Since I’ve always been interested in the mechanics of customer experiences, when I try a new service I like to break down what works and what doesn’t. I’m going to do this on the blog periodically under the title “What’s Worth Copying”.

So here’s WWC #1. The other day I had to get rid of a bunch of old furniture that was living in my wife’s soon-to-be-former garage. We’d arranged for a charity to come pick it up, but they screwed it up twice, and we were left with just a few days left on the lease and a big pile stuff we were never going to use. If I had all the time in the world I’d have tried to get rid of it on FreeCycle or Craigslist, but that’s not realistic when you’re also trying to launch a startup.

I know nothing about junk removal, but I had seen the ads for 1-800-Got-Junk. Here’s how it went:

What worked well:

  • It was extremely easy to schedule. I went on the web site, picked a time slot (for just six hours later) and got a confirmation of my time slot.
  • The web site signup gathered the minimum information necessary. They didn’t try to get me to create an account, for instance – they created it for me and sent me a randomly generated password by email. All they asked for was name, email address, cell phone and the address where the junk was.
  • Pricing was transparent. They charge by volume, and have a nice little widget on the reservation page that lets you see how much furniture can be crammed in a given amount of truck. It’s very well done, and highly accurate – I was able to tell exactly how much things would cost.
  • The people who do the work were very polite and efficient – they called ahead of time as they were running early, and were willing to wait until the scheduled window if I needed them to. They also spoke excellent English and could clearly communicate the service and understand the instructions I’d given them.We’ve gotten a lot of deliveries recently and this has been a real problem.
  • Payment was easy and flexible.

What didn’t:

  • There wasn’t an obvious tipping policy. At the end of the transaction I realized that I probably should tip, but since I barely ever carry cash anymore, I didn’t have anything to give them. I should say that the guys did not hit me up for a tip or in any way act as if they expected one, which is one of the reasons felt like they deserved one. Since this is a service that most people don’t use on a regular basis, it’s not immediately obvious what you’re supposed to do. I tip movers, right?

So overall, it was a very smooth experience. I feel like I got a good deal – even though I probably could have found the same service for less money if I really looked. So here’s what I think applies to other businesses:

  1. Make it very easy for people to get in and start engaging with your service. When I’m asked to create a password I don’t feel like I’m accomplishing my primary task (in this case, getting rid of a pile of junk). Entering my address does feel productive because I know the truck is going to have to find the house.
  2. Don’t let customers be unpleasantly surprised. Transparent pricing is even more helpful when the customer doesn’t use the service very often. The “how much fits” applet on the reservation page is a really nice touch, since it meant that I didn’t have to spend the day worrying that I’d be charged $1,000 for rubbish removal.
  3. If people are a vital part of the service delivery loop, make sure that they’re trained well enough to avoid frustrating the customer. In this case, there was a pile of stuff in the garage that wasn’t supposed to go, and I felt comfortable pointing that out and then going upstairs to do something else while they loaded the truck. And lo, they didn’t screw it up.  I suspect I paid a premium for this.

At this point, the temptation is to sign off the post with “And that’s What’s Worth Copying.” But I won’t.

 

Agenda for 2012 – What’s so interesting, anyway?

Posted on by

I have a long and complicated relationship with blogs. My first attempt was in 1997, hosted on my personal site at Yale. The term “blog” was a couple of years from being coined at that point, so the site was a set of essays in the style of Philip Greenspun, who had recently invented Internet-based exhibitionism (in a good way). This was all wonderful but lead to one major problem – I didn’t really have all that much to say. I was in college, and still working on my first startup. So I was learning a lot, but I hadn’t come to very many firm conclusions. When I graduated and that site slipped off the Internet and was not much missed.

Subsequent blogs included a personal blog (2001-2003), an O’Reilly Network blog (now apparently lost to the web as well, although it did feature a great review of various trade show tote-bags), and blog I started when I went to MIT for graduate school. The latter was essentially killed when I took a job working on healthcare IT policy for the US Government, and was told that I really couldn’t publish on any topic which was in the general remit of my job or my agency. At the time, that was almost everything I was likely to have a comment on.

The original incarnation of info.rmatics (this blog) was a group effort with some colleagues. That worked pretty well, but we never came up with a consistent voice or focus. Readers who were interested in hearing about JavaServerFaces didn’t want to wade through discussions of FTC disclosure rules for breaches of confidential patient data. The reverse also applied.

The strange thing is that in more than ten years of blogging I never really allowed myself to just sit down and write about what was interesting to me at the time. If my ruminations are useful for other people, that’s great – I hope they are. But I’m not going to worry about making every post interesting for every potential reader (although you can always subscribe by category).

Here’s the list. Off the top of my head, at 1:10 pm, Friday, December 30th, 2011, as I sit in a Starbucks in Southborough, Massachusetts, waiting for the nice people from 1-800-Got-Junk to call me to confirm that they’ll be coming to pick up a large pile of old furniture from my wife’s old house down the road. This is a unique moment in time, and I reserve the right to be distracted by other bright, shiny ideas at any point:

Business

  • What’s fundable and what isn’t? What makes a start-up likely to succeed?
  • Angel Investing. How can you create a strategy around small investments in very early stage companies?
  • Sales and marketing. Simple products solving common problems are great. But what happens when you have a (moderately) complex product that solves a complex problem? How do you reach and educate your potential users.
  • Measurement – how can you tell when a team is doing well? What metrics are most useful for companies at any given size?
  • Customer Service – how can you create the best possible experience for your customers even if your resources are highly limited?

Healthcare

  • How can we make the healthcare system more consumer-friendly?
  • How can we take waste and repetition out of healthcare delivery?
  • How can technology make life more fun and rewarding for physicians? Today’s electronic health records and related tools are a burden for clinicians – rare indeed is the doctor who will tell you that their tools make them a better physician.
  • What’s the government up to?

Software

  • What makes a software development team successful?
  • How can groups of stakeholders – developers, users, designers, testers, managers and others – communicate their ideas cleanly and effectively? Previous experiments in this area helped spawn the Clickframes project.
  • How do you hire and retain a talented software development team?
  • What’s the best way to use Microsoft technologies to build a scalable web-based application?
  • What’s up with HTML5 and JavaScript? The old patterns for building web applications are clearly obsolete. Books that I wrote six or seven years ago (and which provided great advice back then) are not merely out of date, they’re positively dangerous.

Everything Else

  • Cameras. Cool technologies. Current affairs.

And so that’s the agenda for 2012 and beyond.

 

Expensify: A Case Study

Posted on by

I hadn’t heard of Expensify before I saw a TechCrunch piece on the company this afternoon. I happened to have several expense reports outstanding for a consulting client. I hate doing expense reports – scanning all the pieces of paper, putting together a cover document and putting everything into a PDF. Except during the relatively rare interludes in my career where I’ve had an assistant I can thrown receipts at and then race out of the room (Hi Andrew!), I’ve always been really bad at these. I have no excuse: my first boss taught me many useful skills, and precise receipt keeping was one of them. I just hate doing the reports. For that matter, I was never all that good at getting the receipts to my assistants.

Expensify LogoSo after reading the TechCrunch article I logged into Expensify, and half an hour later all my consulting expense reports but one were done and sent off. All of my expense reports for Linked Medical, our new startup, were done too, and filed in the “pay when we have more money” bin. I don’t think any web based tool has ever become so essential to me so quickly. One of the first “ASP model” web applications I ever used was the Ariba purchasing system, after my early-2000s startup became part of a much larger company. It was truly terrible. Fortunately I had an assistant.

Expensify’s product is pretty far from that original Ariba system. Sure, the software isn’t perfect, and a few of the rough edges are downright weird considering the overall level of polish (uploading a “.htm” file receipt gives you an error message, while “.html” works just fine). But they did at least six things right, and those six things are relevant for lots of different applications:

  1. Make it brain-dead easy to start. I typed in my email address and was done. They sent me an email which I later clicked through to set my password. There was zero friction, which is incredibly important. I could also have logged in with my Google credentials, which is a nice touch – but this was actually faster.
  2. Make it easy to explore. The home screen is a series of big boxes identifying common interests for new users. I’d heard about the mobile tool first, and it was one click to learn more. The basic navigation is very simple, and maps to things like “Receipts”.
  3. Use Mobile for the right things. This is really important. I do not want to create an expense report on my Android phone. I probably don’t want to create one on my iPad either. When I’m mobile, I want to do one thing: easily record expenses. So the mobile app does that very well – I can photograph a receipt with my phone, and/or enter expense details on a simple screen. There are two big buttons when I open the application, one for each option. It’s very responsive. And I don’t need to keep the small receipts anymore.
  4. Integrate seamlessly, but don’t make me do it first. Another box on the home page is “Link Credit Cards.” It took two minutes to link in my American Express, and then I had a huge list of transactions to choose from.
  5. Give me multiple avenues to learn the software. I can add expenses to a report from the report, or I can look at expenses and add them to a report. Same with receipts. I never found myself having to go back into the wrong area of the application. When I looked for a feature, it was there.
  6. Don’t make me learn the whole thing. Expensify supports “policies” for corporate expenses. There are some other features there too around submissions and approvals. I don’t need those yet, so I didn’t have to use them, learn about them, or worry about them. As it happens I have looked at them, and they’ll be useful in the future – I just don’t need them now. Complexity kills, especially when you want casual users to adopt a system without external support. Expensify landed me as a customer because I was able to finish an expense report in 15% of the time it would have otherwise taken.

They also do a good job of thinking about ways that new technology lets you change the underlying workflow of an old process. In this case, it’s expense reports for receipts under $75. If you link a credit card, you can import expenses and the system generates an “eReceipt” for that charge. Expensify prints it in the report and adds a bar-code, and it can be verified with the site later. The company will stand behind the fact that the expense was imported from a credit card statement, up to and including during an audit from the IRS. If your corporation accepts the eReceipts, you can stop carrying around those little printouts from taxis. This is something that the old Ariba system – or any non-cloud expense account system – simply can’t provide, because it relies upon the trusted connection to the credit card company, and on Expensify’s willingness to stand behind the integrity of that data.

When turning workflows into products, it makes to ask what capabilities are available now that weren’t available on paper or weren’t possible electronically with the technology of a few years ago. The eReceipts are a great example of this. Development for the iPad should be triggering a lot more of this kind of lateral thinking, as we all adjust to touch-and-swipe interfaces instead of keyboards and form fields.

Naturally there are a few things Expensify can improve on. I’m glad I didn’t need to take a training course to use the tool, but a five-point introduction to the core concepts would have been nice. The most opaque thing about the system is the relationship between receipts and expenses. It’s not actually all that hard to figure out, and the system gives you helpful messages. But an introduction presentation would have made things clear from the get-go. Dropbox does a great job with that.

Any time you’re asking users to think about the attributes of a data model you’re asking for a certain amount of trouble. In this case, the idea of “reimbursable” and “unreimbursable” expenses also needed some clarification. Since I was in consultant mode when I was doing today’s reports there’s no concept of “unreimbursable” – but I’d unclicked the default when I was linking my credit card because I thought that leaving it as “reimbursable” would make more work for me as I filtered through expense lists. It turns out this is useful for corporate cards, which makes sense – but I’ve never carried a corporate card where I didn’t get the bill myself (oddly, this was true even when I worked for the Federal government).

The bottom line: a very useful service and a great source of ideas for making other web applications easier to use. Oh, Expensify guys -please add an “email receipt” feature like TripIt’s, if you haven’t already.

Hiring Programmers – The One Question Interview

Posted on by

First off: the blog is back. I will refrain from commenting at any length on why it had gone away, as introspective blog posts about the process of blogging are boring. Sometimes you’re blogging a lot, sometimes you’re not.

I’ve been thinking a lot lately about hiring programmers. I’m launching a new venture, and I’ve been very luck to bring one of my favorite people on board to lead our development team. He’s brilliant, hard working, polymathic and generally willing to dive into things which have to be done but may not be massively interesting. I’ve hired a few other people like this in the past, and when I have the opportunity to hire them again (and the role is appropriate) I always go for it.

I do that because it’s a complete crap-shoot otherwise.  I’ve got it easy – since I wrote a few books on software development between the late 90s and middle 2000s I have a good reputation as a boss who knows how software gets developed. That’s made it easier for me to attract top tier people – much easier than if I was a pure business guy, regardless of however good a business guy I may have been.

So I enjoyed reading Jon Evans’ Why The New Guy Can’t Code. It’s a nice overview of some of the pathologies, particularly the idiocy of the brain teaser interview. Evan’s suggestion is that you don’t even bother interviewing people who can’t say “I got this done” where “this” is a self-contained project. And I basically agree.

The guy I brought back for the new company has been a friend for fifteen years. We went to high school together. So when I hired him I was cheating – I knew exactly what I was getting into (and I made sure my then-business partner was on board so that I had a check on any desire to hire a friend). After that point, however, I was out of rock-star friends who were looking for jobs, so I had to go looking the more conventional way. And in each case, the interview went the same way – we sat in a room and talked about projects for an hour. In some cases I had other people on the team do more conventional technical interviews, but I usually found I didn’t need them – by having someone clearly explain what they had done to build an application I could easily tell whether they actually had the skills they claimed. I could also tell how they worked in teams, and how they thought about problems.

The sample size is pretty small – maybe 30 people interviewed over the last five or six years. And everybody we hired wasn’t perfect. In those cases we usually had some misgivings to start, and we corrected fast. But by and large, we got the rock-stars, or at least the guys in the band. And we never had an issue with competence.

Of course, having a good HR department that knew how to source candidates properly (by going after the already employed at companies that were closing up and filtering out the top few people) helps. But the best people can have a conversation. And phone screens help – you can start this discussion on the phone, and if they can’t start telling you about a project they did within the first few minutes, time to move on.

Another good take on this issue is Why Can’t Programmers.. Program? which describes a great simple test to weed out the obvious non-coders in five minutes or less. Surprisingly, it excludes quite a few people with C/S degrees.

 

How to Scope a Product

Posted on by

I wrote about the demise of Google Wave earlier this week. MG Siegler over at TechCrunch wrote yesterday that Google didn’t give it enough time, and mishandled the launch.

Google definitely mishandled the launch. They made a big announcement but then trickled the product out slowly, wasting most of the initial enthusiasm. In our work we try to go the other way – to get a few key influencers in an organization excited about what we’re doing and let them evangelize their colleagues. That way when the big announcement happens there are already people using the system and ready to support the new arrivals.

I disagree with Siegler’s statement that Wave didn’t solve a problem, though. He wrote that it doesn’t matter, since Twitter doesn’t solve one either. I think it does matter – because Wave did solve a problem. It just wasn’t as big a problem as “the way we communicate doesn’t work.” Google Wave was an excellent email replacement for a certain subset of emails – messages where a small number of people collaborate back and forth on understanding a problem and forming a strategy. This is a critical problem for small and medium sized organizations. And I suspect that if Google was to go back and look at their internal use of Wave they’d see the use case. I wrote about this in my first post, so I won’t re-hash the mechanics here.

So my lesson from this – beyond not trusting Google beta products to be available for my use over the long term – is that when you launch something big you have to launch it small. When I talk about product development at conferences I like to use the example of Flickr. Flickr, today, is big – it’s changed the way that we deal with images. But the original problem was small – sharing pictures online, easily, with friends. Searching billions of images for creative commons licensed pictures to spice up a PowerPoint presentation came later. Hindsight is 20-20, but Google should have found more small, real, value-from-day-one problems that Wave could solve without requiring everyone in the world to adopt it at once. Once I figured out it was useful, I was able to drag my team along by fiat, and we all started evangelizing it to others via our separate projects. Everybody almost won.

The End of Google Wave

Posted on by

Google killed Wave on August 4th. I wrote a bit this morning about Google Wave and knowledge worker collaboration over on the Beacon 16 blog, so if you want to know more or less what I’m talking about, check that one out.

What I liked about Wave from the healthcare perspective was the way it managed conversations. I could easily see the platform extended to care planning and coordination, and I had some fairly specific ideas along those lines. They may still see the light of day in the context of some our other projects – the idea of replacing chains of email with something that was just as easy to use but created an automatic running summary of the conclusions drawn by the group (and which made it easy to reconstruct the discussion behind that reasoning) was extremely compelling.

New Job, New Blog, Same Team

Posted on by

The last few months have been quiet on the blog for a couple of reasons. The biggest one is that I’ve been getting ready to leave my position at Children’s Hospital Boston, where for the last three years I’ve been Director of the Informatics Solutions Group. There were a couple of reasons for us to move on – the biggest being that the scope of interesting projects outside Children’s is so tremendous right now. And we’ve got a couple cooking, including one that’s not quite ready for a blog-announcement yet (but it will get there).

The other project is Beacon 16 Software, a new consultancy focused exclusively on design, development and implementation of advanced Healthcare Information Technology projects, along with several members of the ISG team who should be familiar from this blog. We’ve already done work for some of the major Boston hospitals, and this week – our first outside CHB – we’ve started a project to implement the remaining Meaningful Use functionality for a major hospital. We’re also working with startups to develop products and demonstrations in both clinical IT and life sciences. And I’m not above asking my blog readers for work – if you’re looking for a group that knows this industry up and down and has a great track record building cutting edge software, give us a call. We’re even remarkably affordable.

We have a new Blog on the Beacon 16 site as well. The focus will be Healthcare IT and software development. If you liked this one I think you’ll like that one. We’re re-running a few of this blog’s greatest hits, and the first new post is up now, talking about how to make product users into product champions.

I’ll also be keeping this blog going, although I’m going to pull the focus back a bit (probably no more posts on JSF and software engineering – we were getting our audiences mixed up). Instead I’ll be focusing on aspects of HIT development and healthcare policy that don’t belong on the Beacon 16 blog, and probably recount some stories of what it’s taking to build a small company. It may very well be interesting, so stick around.