This Blog is no longer active — it has been relocated to http://johnpeltier.com/blog. Please join me there!
I’m writing to share a couple of observations about ATM machines. As long as they’ve been part of our lives, it’s only in the last few years as a Bank of America customer that I’ve seen those products evolve. Today, I observed a truly revolutionary modification that saves two steps in every cash withdrawl:
The entry of PIN number and selection of fast-cash amount were on the same screen.
In every previous interaction with an ATM, after inserting my card, I’ve been conditioned to (1) enter my PIN number, (2) click a button, (3) click a button for “Fast Cash,” and then (4) select an amount. In today’s interaction, some significant experience design had been applied. Though a single example does not demonstrate a pattern, I’d be willing to bet that my experience is not unusual: 99% of my transactions are fast-cash. So today’s interaction was much much simpler: (1) enter PIN, (2) select fast-cash amount. Choosing the fast-cash amount triggered the ATM to validate my PIN and dispense the cash. That saved 2 steps, or 50% of the work required of the user. Nice!
The only question I’m left with is: Why did this take until the year 2009?
Further, possibly because I was distracted by the unusually efficient interaction, I do not recall being forced to request a receipt. In previous interactions I’ve been annoyed with BoA ATM machines that display a message “Retrieving preferences,” and then immediately ask if I want a receipt. My receipt preference doesn’t change: I want one. I realize the bank would prefer I do not, but their opinion is irrelevant. If you’re going to store my preferences, and you insist upon asking me that question each time, the profile you’ve assembled is incomplete. But as distracted as I was, I cannot swear that I did not have to answer that prompt: and believing I didn’t would be too impressive of an example of interaction redesign for me to handle.
How many more everyday interactions can be made dramatically better?
Before I begin, I’ll issue a warning: What you are about to read is not advisable, though it is a first-hand account. (Also, I wish to credit Scott Sehlhorst for inspiring my commentary by his comment about this topic in this post about agile prioritization.)
I’m currently running a large development project which is transitioning at the 2/3 mark from waterfall to agile.
Now that I have that out of the way, a little background. The project was defined in terms of discrete requirements, originally tied together with a few key workflows and wireframes, and involves an n-tier architecture with a number of moving parts. Though much of the underlying architecture was completed, we weren’t clear enough about the workflows and stories and the project was not producing tangible results fast enough. So, while we recognize we should have started with agile, the company hadn’t adopted the agile methodology at inception. To achieve our goal of better predictability and periodic peer review of the software, after it became possible in the corporate environment, we moved to agile.
Note that in the first half of the project, we erred on the side of providing requirements that stopped at the “what,” rather than providing the team enough about the “how.” The move to agile has exposed that we weren’t providing enough context around each requirement (story) to enable the development team to build the product. In this case, the complexity of the project and an unfortunate number of unknowns has made it useful for product management to collaborate with user experience well before presenting user stories to the development team, as advocated by others, rather than attempting to involve UX on an “as-needed” basis for each story. In prior attempts to provide only the agile user story in “As a ___, I need ___ so ____” format, it quickly became apparent that the story wasn’t nearly enough. We had to deliver the agile user story with the workflow steps (including interaction design) — only that seemed to eliminate enough uncertainty to proceed.
From a higher level, there’s another lesson here that operating under both paradigms has exposed. It was quickly clear that for a complex system, providing the complete user stories and supporting material (including workflow steps, interaction design and wireframes) enables undesrstanding and fast action. Though it was in some ways coincidental that we had wireframes before our sprints kicked off, it already appears to have sped things up significantly.
Hopefully the ramp-up will expand as we continue down this path, and we’ll reach the finish line quicker than we might have otherwise.
As I spend more time in startup-heavy Austin, I think more about the role of product managers in startup companies. In most cases, that role is implicit–there is no “product manager,” per se, but rather a CEO and/or CTO who have a vision for a product and who chair a personal quest to bring it to market. There is plenty of risk here for those who understand product management and have delivered products to market.
The fact is that as demands placed upon a startup company mount, the focus of the CEO begins to split to operational and technical issues. If someone is not dedicated to the product itself, it seems very easy — to cite but one example — to experience feature creep where people think additional functions “can’t hurt,” while they’re really not focused on the specific target market and whether or not that target market will actually use the feature being considered.
In a recent On Product Management post and the related comments, several of my peers argue for hiring experienced product management early in the life of a startup to avoid missing the target and delivering a product that isn’t a winner. I hereby add my “ditto” to those opinions.
Attendees at each of the ProductCamp “unconference” events held in Austin have provided feedback reqeusting more frequent events for the product management and product marketing communities. In response, the folks behind ProductCamp have unveiled a smaller version of the unconference, calling it ProductPotluck Austin. Before you make any plans, be sure to “bring ideas — not food.“
The agenda includes networking and 2 presentations, to be voted upon by the attendees. For the first meeting on October 21, two topics have been selected: Marketing and Product Strategy. Participants are asked to submit topics, and registered attendees can vote upon the sessions offered between October 12 and October 16. On the 21st, the participants will vote from among the top 4 vote-getters to determine the two topics to be presented that evening. Much like ProductCamp, this format engenders a bit of good-natured competition and brings out better presentations.
We hope that this periodic mini-unconference between the biannual ProductCamps can help advance the product management and product marketing community in Central Texas.
Currently, 54 people are signed up out of a maximum 150. Hope to see you there!
NOTE: Please see Paul Young’s more extensive write-up of the event.
I’m reading an interesting book by Denis Hauptly called Something Really New, which purports to boil innovation down to 3 simple steps:
1) What is your product used for?
2) What are the steps that compose that task, and can any of them be removed?
3) What is the next thing the cusotmer will do after using your product?
Hauptly points out in the book that there are two types of innovation, essentially incremental and wholesale, and this type of three-step process is more applicable to incremental innovations. The small (incremental) innovaiton is not necessarily less valuable to a company, and it is more likely to be teachable. By honing one’s focus on the purpose of products and the specific steps of the tasks they enable, attention is being focused on workflows and on looking for opportunities to optimize.
How does one reach life-changing innovation? Is it the same as incremental, but just a better target for optimization? Or is it something existential that may only happen to people in a hightened state of mind or with higher skills? I suppose if I truly knew the answer, I’d be a more successful innovator! That said, while I think creativity and skill plays a great part in it, innovation is probably not as likely if one doesn’t focus attention on the steps required to accomplish tasks, and the tasks which come before and after a task–which is what this book helps to do. For communication of that mindset, I find it valuable.
One of the takeaways I’m finding in Bill Jensen’s book Simplicity is a reaction to the effect that information overload has on company productivity. As there is more and more information to process to do one’s job, it becomes ever more important for a company to provide tools that not only provide access to information, but which help interpret the information in the sense of analytics. So how does this manifest for a large company aiming to produce streamlined products for the marketplace, that will address (and solve well) a specific problem?
As a product manager with a multinational corporation, I find that (at least at my company in my specific division/subsidiary) there’s a contrast between the streamlined solutions we’re being asked to produce, and the cumbersome internal systems we use to collect and analyze the information we use to design such products. The systems we’re building are “push,” but the systems we use internally are “pull.” Some of this may be due to our company’s implementation of off-the-shelf requirements management and project management tools, but the net result is that the company does not make it easier to easily understand the decisions we need to make, much less make them.
I suspect we are not nearly the only ones.
One of the products I’m developing now is a service which can run client-server or on the web, in order to maximize the base of customers to whom we can provide a solution. I’m finding that questions about–and design of–the internal management components to be used by company support representatives are getting short-changed due to the pressure to meet release targets. This is certainly not unique to this one product, and the support angle hasn’t been ignored, but at the same time the support team’s “use cases” have not been considered with nearly as much diligence and interaction design as the product itself. So in one sense, the sub-optimal experience product managers have with requirements tools is being propagated to the experience support reps will have with service management.
Something I need to reiterate within my organization.