Agile Product Strategy, Marketing, ProductCamp and more.
RT @celia: (via @StephenFleming) Steve Blank: "The golden age of Silicon valley is over..." m.theatlantic.com/business/archi… @sgblank
User Experience
Buyer and User Personas – the Presentation
0161 days
The Startup Slingshot was gracious enough to offer me an opportunity to deliver my Buyer and User Personas session that I delivered at ProductCamp Atlanta with co-author Kevin O’Malley, and alone at ProductCamp Nashville, in the form of a video blog post.
If you have 25 minutes to burn, here’s the presentation:
Product Management and Solution Design
3185 days
A valuable reminder was posted by Martin at Mind the Product today about focusing product management attention on the problem space, rather than the solution space:
At a ProductTank last year one question from the audience made me want to jump up on stage and answer it myself – “where’s the innovation and creativity go if product managers are defining all the products?”. Stop, I wanted to shout, you’re doing it wrong….Product managers should not focus on designing solutions – they should focus on defining and prioritising problems.
Product managers generate value for their companies by finding market problems that potential customers will pay to solve, and then leading the process of finding a feasible and compelling solution.
This does not mean the product manager designs the solution, in fact, many are not trained to do so. That distinction is drawn clearly in a post from 2005 by one of my favorite product management writers, Roger Cauvin:
A product manager determines the requirements for a product, but not its design. Thus a product manager specifies what a product should do (functional requirements). She also places constraints on the product’s behavior (nonfunctional requirements), such as how easy to use it should be. But placing constraints on a product’s behavior does not mean specifying the product’s design.
A product manager is uniquely qualified to learn what the market demands and translate this knowledge into product requirements. But only an ergonomist or user interface expert is qualified to design a product that satisfies these requirements. How many product managers are trained in user interface design?
It is far different to find–and then define–a market problem than it is to figure out the best way to solve it. Many are guilty of confusing the two.
Where it concerns product design, I subscribe to the Marty Cagan “Product Discovery” model for designing winning products. In Marty’s model, the product manager brings an understanding of market problems to the table, and collaborates with the other two key members of the product discovery team–the user experience designer and the lead developer–to discover the right solution. That solution is discovered by brainstorming, generating a high fidelity prototype, getting real user feedback and then brainstorming again to iterate on the prototype, repeatedly until an optimal solution is “discovered.”
The key point relevant to Martin’s article is that the product manager isn’t designing the solution–the product manager leads a team of three to design the best solution. Marty explains in an insightful post on designing winning products in a large organization:
The key for every product discovery effort is to identify the three key people – the product manager, the user experience lead, and the product development lead. These are the three minds that must collaborate closely to solve problems in new and useful ways.
I’ve seen teams repeatedly in which user experience and product management collaborate on their own to create a design, and then find out too late that the design either (1) just won’t work, or (2) will be too costly to deliver to market in an acceptable time frame. The design isn’t the purview of the product manager individually, nor is it that of the lead developer. Product design is a collaborative effort.
Here’s Marty discussing, as he calls it, the Product Discovery Team:
Personas in Design and Strategy
0250 days
At ProductCamp Atlanta 5, I co-presented a town hall session with Kevin O’Malley about the use of personas in Design and Strategy. Our assertion is that a persona effort is a wise use of a product manager’s time, because it can lead to both a better-designed product and a better-aligned marketing effort, which should lead to better results.
A significant amount of research goes into developing personas, and because of the “town hall” format, we only touched on that in this discussion at a high level. The key point is that the research must be first-hand, and the persona cannot be “made up” based on demographics and abstract data alone.
Once realistic personas are created (with real names and other details) we then must engage in a socialization effort, which is beyond the scope of this presentation. Suffice it to say that the personas must be brought to life, and the key players must get to know these personas as if they are real people. In response to a question, I cited that in the persona effort I led at Carestream, we had our personas email our team regularly to provide ongoing interaction and a steady flow of realism to paint the picture even better. If the team isn’t on a first-name basis with the personas, they aren’t doing any good.
The key benefits to investing in a persona effort are:
- Buyer personas: By crafting marketing collateral for a specific “person” or “persons” instead of the generic “the user,” we get more targeted language that our target audience can really connect with.
- User personas: The product itself can be better designed to meet the needs of a specific target market by designing the user experience for a specific “person” or “persons.”
One key point to make is that to achieve everything listed here, there are often two sets of buyers (particularly for B2B software) because the buyer is NOT the person using the product!
The slides we presented are on Slideshare:
Personas in Design and Strategy
View more presentations from John Peltier
For more background, please reference this article by Steve Johnson at Pragmatic Marketing.
The Product Owner Vision
0503 days
A recent article by David Alfaro summarizes well the core competency of a product owner in scrum / agile development organizations — the ability to consume all the inputs, mix them together and design a cohesive, marketable product that will meet the needs expressed in the inputs. Not surprisingly, this sounds a lot like product management. Here’s how Alfaro expresses this core skill:
After you have listened to all the aforementioned stakeholders the following two hardest steps are ahead: 1) Synthesize all that input into something really remarkable, feasible to implement and affordable for customers. 2) Communicate that synthesis to stakeholders and team in order to go for it.
There are (at least) two major views of this. Design-driven organizations would likely agree with Alfaro, perhaps with the added input and agreement of a design team (artists and interaction designers) on the front side to craft the behavior of the desired product. Others that take a more “agile” approach may guide the product owner to focus on the problems, presenting them to the team in the form of stories and allowing the team to design the solution within a pre-determined set of parameters.
Either way, the product owner’s job is to define with more or less granularity the “what,” and to guide the team to analyze and implement the “how.”
Four Artifacts to Define a Sellable Product
2657 days
Recent work on business plans and business cases refocused me on the need to document for a wide audience the purpose and design of a product, within the context of how it would be delivered to market and how it would prove profitable. As I reflected upon this, it occurred to me that a concise package could be assembled that delivers all the information needed to evaluate a product.
I’m sure someone has thought of this before, and there’s probably a formal name for it, but I thought I’d document it while it’s in my head….and before I delete the email in which I decided to capture it.
1) What Problem is Being Solved: The overarching product summary should start with a definition of the problem(s) being solved. From this definition, anyone reading this package can evaluate whether the proposed solution addresses the problem or problems stated. Much expense can be saved by not delivering a solution to market that doesn’t address the intended problem.
2) Buyer and User Personas: Who is the primary user for whom a product is to be built, and who is the buyer actually responsible for the decision to purchase? Often times these are not the same people–a proper user persona can identify the user’s tendencies and the typical person who will be using the product, whereas a buyer persona can help to keep the buyer’s motivations in mind.
3) Value Proposition: A succinct explanation of how the product can provide tangible, financial benefit to the user. One method is to show the value of the time saved by elimination of manual steps, which can show the value of efficiency. Increased revenue may be harder to validate, but using reasonable estimates can help to show the exact amount of value that a user will obtain by using the product. This evaluation is helpful when it comes to pricing the product for the market, and should take into account how the solution solves the stated problem for the buyer and users defined above.
4) Solution Workflows: For a software product, no presentation of the proposed product is complete without a robust set of wireframes weaved together with a good story. Packaging this all together helps answer “what are we building, exactly?” and helps build the case that the solution proposed is indeed the best one, for the conditions in items one and two above.
There are other items packaged in a business case — in particular, one that comes to mind is a pricing proposal — but the items listed here are enough to deliver to business people within a large software company to make the case that a particular product is solving a real market need for real users, and to explain exactly what product is proposed to meet that need.
ATM Observations
0879 days
by johnp
in User Experience
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?
RealClearPolitics
01126 days
I have no intention of getting into politics — i just want to point out a site that continues to draw me back for repeat visits. RealClearPolitics is a news aggregator that’s been around since 2000 apparently, but which I discovered in the run-up to the 2008 Presidential election. In today’s hyper-partisan climate, it’s hard to find many sites that simply make it easy to keep up on current events with a balanced perspective.
This RealClearPolitics.com does by focusing on a couple of simple user experience premises: content and simple presentation. For the time that I’ve been visiting the site, the articles selected are chosen from right, left and center-leaning news sources ranging from such selections as Investors’ Business Daily and Weekly Standard on the right to Slate and the New York Times on the left. That alone is worthy of merit. Deeper review might include analysis of the site’s selection of polling numbers, its editorial content, and the percentage of articles from each side. My cursory evaluation of the site’s cross-section of polling numbers showed a wide enough variance to appear solid, and I’m not reading enough of the articles to comment on the site’s own editorials. All I know is that from my marginally-interested-observer perspective, the site gives me what appears to be a balanced cross-section of opinions and facts.
As for presentation, the site is relatively well organized and easy to figure out, and the links are provided in a plain yet readable format (much like the plain text link approach of Reddit.com). The site won’t win any Flash animation awards, but it’s not intended to. What the site aims to provide, it does in a fairly attractive, functional presentation. In a field where success in “web design” typically refers to the latest AJAX or Silverlight components, sometimes what makes a good product is an ordinary-looking site with quality content. Who knew?!
Recent Comments