Agile Product Management, Marketing, and More
Archive for May, 2009
Can Palm come back from the Dead?
May 19th
By now, everyone has heard about the hype of Spring 2009, the Palm Pre. The release is finally confirmed to be taking place on June 6. Many are asking, can the device possibly live up to the glowing reviews?
Let’s look at this from a slightly different angle–I think it’ll be fascinating either way. Look at the amount of brand publicity Palm has gotten out of this device! For a company that became a household name ten years ago with the Palm Pilot line of products, it’s been a rough ten years watching that name fade in its influence until it was practically swallowed whole by Apple when the iPhone was released. I think this is one of the contributing factors to why the Pre is getting so much pub, but there are a couple of others:
- people who think Apple needs a solid competitor in the consumer space
- perceived quality of the WebOS “card” UI
- need for a new “story” to fill the pages of technology blogs
- Palm loyalists who want to get away from Windows Mobile
- everyone loves an underdog
Yes, I’m stretching here. I’m not exactly sure what is really motivating all this attention. I really think it’s blog filler–I’ve had two Palm devices over my lifetime and own one now (the 800w), which sadly I’m contractually committed to until June 2010, but I’m definitely a late adopter. I’m still waiting to see if that whole “computer” thing is going to take off.
One thing Palm is actually doing right is involving developers early, to jump start the “app store” concept. Palm recruited a bunch of developers to have a look at the OS and got impressive feedback. Developers are already organizing BarCamp-like PreDevCamp events to collectively organize and learn to develop for the new OS. So part of the seed behind the hype is winning over the geek squad.
Still, this won’t succeed if it only wins over the technical folks. Simply put, this product must win over the consumer–and that battle starts June 6. has already begun.
So many products, So few solutions?
May 17th
Healthcare IT is on the minds of many as federal funding is being waved like a carrot to optimize Healthcare IT by 2014.
One important question is why, given that there are any number of vendors already marketing electronic medical record (EMR) products, this area is considered to be so lacking? Is it that physicians aren’t adopting these solutions, or are the solutions that exist not meeting the needs of the market (and, in turn, the American healthcare consumer)?
I believe it’s both. I also believe it’s far too big a problem to cover in one post, much less one blog. Or book.
Adoption rate of electronic health record (EHR) and EMR software is nearly 40%. A number of factors are acknowledged to play into this, both at the practice level (cost, perception of expected productivity gain, physical space) along with legal and business reasons such as ownership of the EHR itself and competition. Certainly there are more, and I make no claims that this is an exhaustive list.
I do find it interesting that several of the reasons in this non-exclusive list are related not to the technology itself, but rather to fear: fear that (without committing fully to the EHR implementation) the productivity gains promised won’t be realized, fear about the legal repercussions of collecting cross-provider data into one record, and fear of making it too easy for a patient to go elsewhere.
Sam’s club is attempting to address the cost concern, and the federal stimulus money should help with this barrier. Technology continues to evolve into smaller, more targeted form factors and purpose built devices – this trend promises to address concerns with space in the clinic, and fitting office technology into a clinical setting.
One overarching challenge is that even if we overcome all of these factors — including the fears of legal and competitive concerns — and doctors all get on board and decide to share their patients’ information in the interest of improving care, there is an underlying challenge with transferring information from practice to practice: semantics. From practice to practice, a condition or a treatment may be coded with similar but unequal terms. Either these unequal terms must be linked to the same code to allow the system to resolve the discrepancy, or the system must learn to interpret the language well enough to identify cases where distinct terms are not equal and when they are. Otherwise, what is delivered from one practice to another must be displayed to the clinician for translation and action, rather than acted upon automatically.
So what’s the solution? Is the problem technological or interpersonal?
Twitter overestimates itself on the diffusion curve
May 12th
Twitter posted news on its blog today, and briefly on the service, that they are removing one of the settings for @replies.
Based on usage patterns and feedback, we’ve learned most people want to see when someone they follow replies to another person they follow—it’s a good way to stay in the loop. However, receiving one-sided fragments via replies sent to folks you don’t follow in your timeline is undesirable. Today’s update removes this undesirable and confusing option.
What Twitter reads as “most people” is clearly not the power users, who are using Twitter actively to build networks and reach out to people. That group of power users–a persona, perhaps–is distinctly vocal, and so within moments of this change being announced, blog posts from heavyweights like TechCrunch to personal (but busy) blogs from industry veterans like Whitney Hess all lambasted the move immediately.
How can a company with a clearly scoped, profitable product like Twitter not understand this? (oh, wait..) I believe Twitter is victim of its own hype, and doesn’t know its own location in the product lifecycle. In terms of the diffusion curve, I would estimate Twitter is somewhere in the “early adopters” stage. Until about 6 months ago, it was used innovators only–and heavily dominated by the power user persona who would be offended by a setting like this being removed. As a few celebrities and news networks have jumped on board, the media thinks Twitter is now “mainstream,” but try this test: Go ask 10 of your non-technology friends whether they use Twitter. Even better, whether they understand it, and whether they access it from a mobile device. I bet you get less than 2 who answer yes to the last 2. Twitter is NOT mainstream.
Given that, Twitter should be focused on those power users who make up the innovator and early adopter group–people who like to tweak the experience to their tastes. Instead, they chose to not only remove a useful option, but even worse phrased the rationale as removing an “undesirable and confusing” option. Way to talk down to your user base!
Very bad move, guys.
UPDATE: Turns out there was a technical limitation, so the rationale given was bogus to begin with. So not only did they insult their most technical users, but they lied to them about a technical problem.
Quality Products and Product Quality
May 12th
I changed my tagline today, and I wanted to write down what I meant before I forget. 
The motivating factor behind every purchase is a need that a person seeks to fulfill. It stands to reason, then, that a product that fails to meet the need it claims to fill is not a quality product. Whether that’s because it’s designed poorly and doesn’t accomplish much of anything, or because it is designed well but meets a different need, if it fails to meet the need the buyer purchased it to fill, it is not a quality product to that buyer. Across the chasm, once we find a product that meets a need, if it suffers from reliability issues and just flat-out doesn’t work well, it suffers from poor product quality.
In the lexicon of software quality assurance, these concepts are described in terms of verification and validation–verification answers the question “are we building the right system?” and validation answers the question “are we building the system right?” This demands that an organization push quality assurance up from the end of the SDLC towards the beginning, so that QA Engineers are involved with the initial design and specifications. Additional eyes on design artifacts at early stages of development help to expose potential problems and guarantee more of the right questions are asked early enough for them to make a difference, rather than afterward when the only question that can be asked is “I wonder what would have happened had we….?”