Product Personas

Google AdWords: Costing Businesses More than their Fee?

Google AdWords is wonderful and effective; it's the go-to mechanism for web advertising; and it's relatively inexpensive -- or is it?  

Let's say I am interested in Verizon FIOS, so I Google "FIOS", as below.  There is something very wrong with this picture:

Can you see the big, expensive, mistake?

Answer: I searched for "FIOS" and Google correctly returned Verizon FIOS as the top two non-advertising links.  Google also filled the page with paid FIOS advertising links.  Fair enough, Verizon doesn't pay for the ads unless someone clicks on them.  No cost to Google's client, Google can claim, or only a small cost if the user somehow chooses the ad-link.  But is that so?

Last month, when I ran this search, if I clicked on the non-ad link to FIOS, I was offered a small discount on a certain Verizon FIOS bundle.  Where as, if I clicked on the ad link, I was offered the more discounted bundle options and $150 cash back for the exact same agreement.  (Today, the offer from the ad link is a free HP micro-computer valued at $300 for the same agreement.)  So, the ad link is costing Verizon between $150 and $300 more, per click. And Google also has TRAINED ME to always click the ad-link as I may get a better deal.

A good deal for Google, but not so good for their customer.

Class Notes - March 2009

Scott Warner (BS EE) says: My wife, Mayumi, and I moved back to Japan in 2008 as I took a Hong Kong based position with Cathay Pacific Airways as a First Officer on the B747.  My flying mostly takes me to Europe, South Africa and the US west coast and I also work as a flight data analyst for the Safety Department.  2008 also brought my 20 year Naval career to a close as I retired from the Navy Reserve.  I spend my time off on the golf course in a futile effort to lower my handicap, biking and hiking around Japan, and trying to build my Japanese language skills beyond "Domo arigato Mr Roboto"!

Steve Mushero (B.S. EE, MBA) has left Todou to found ChinaNetCloud, a China-based, China-focused Internet full-service managed services provider that supplies and runs the back-end servers for Chinese game, Internet, and media companies.

Dr. Hooshang Heshmat (MS, Ph.D. MechE), the co-founder and President of Mohawk Innovative Technology, Inc. (MiTi), an applied research and product development company dedicated to green technology, was recently awarded the Society of Tribologists and Lubrication Engineers (STLE) International Award in recognition of his outstanding contribution to the field of Tribology. 

As for me (BS EE), professionally, I am currently working with a small team of ED (Emergency Department, aka ER) docs to develop a computer system for studying and facilitating the quality and timeliness ED specialty consults. Here’s an example consult, “Doctors Neurologist and Psychiatrist, if it hurts when the patient does *this*, why does she keep doing that?”. Personally, a family tragedy has led me into the world of commercial aviation safety. For the past year, I have researched the crash of OG269 in Thailand and the failure of the Thai government to properly investigate, improve safety or ensure any accountability. My work has uncovered compelling evidence of illegal and corrupt actions by the airline’s owner and the Thai Civil Aviation Authority, including the falsification of pilot rosters to hide excessive work hours and fraudulent checkrides. These efforts have, likely, altered the NTSB’s findings of cause. Congressman Frank is now helping determine why/if the FAA via the State Department is not appropriately warning US travelers of the risks of Thai-based aviation. Some of my efforts, and much of the evidence, is posted on the web at www.InvestigateUdom.com.

Advice to BMW, Mini Division

News yesterday was that BMW's Mini division was forced to make manufacturing layoffs due to a precipitous drop in demand for the vehicles.

Let me start by saying, "I love my Mini Cooper S."  Best car purchase ever. 

When I bought my Mini, the dealer told me there was no demographic particular to the Mini.  I suppose he was mostly right, as I haven't noticed standard vehicle demographics such as age or gender or place of residence to be significant ownership elements to the vehicle.  However, it is clear to me that there is distinct buyer persona for the Mini. 

Here are some of the notable elements of Mini Cooper buyer persona, in the US:

• Youthful, want-to-be slightly hip, alternative and quite fun, attitude
• Appreciation for a good handling vehicle
• Willingness to tolerate some minor finish details in exchange for exacting BMW-quality overall performance, a Very High Safety Rating, and an amazing price/performance ratio.

Here is my advice to BMW/Mini: Your marketing department has taken these qualities of the buyer and promoted the Mini Cooper as a toy.  Stop Doing That! 

My Mini fits me, my Newfoundland dog, and a week's worth of groceries for the family.  My Mini fits my child's car seat, her toys, stroller etc, and my husband comfortably.  The Mini is the car to take when we go on a car trip because it gets good mileage, is reliable and makes the trip fun for everyone. (My kid says "You're going fast, mommy", even when I'm not.)  The Mini is also the car to take every time we head into the city for work or for play, because, with the Mini, I rarely have to pay for parking.

In a word, my Mini is PRACTICAL.  BMW/Mini: Market the Mini as Fast, Fun & Practical!

Don't Panic

http://imgs.xkcd.com/comics/kindle.png

Does Kindle2 come with a towel?

Class Notes - Dec 2008

If your definition of looking great is hot, sweaty, a little sunburned and a bit nervous, then, as predicted, we all looked fantastic at our one score reunion.  Dawn McGee (née Mertzer) and I drove to a very comfortable hotel in East Greenbush late Friday night and finished the drive to Troy on Saturday morning.  Upon arrival on campus, we joined our classmates to become reacquainted and work on a cheer as part of the parade of classes that introduce themselves to RPI President Shirley Ann Jackson. 

We were Christine Burkhardt and Rob Lackey and children, Kris Edwards (née Provenzano), Suzanne Cano Meeker and her family, Debbie Haines (née Miller), Michael Jacoby, Christopher Montalbano, Bob Unnold, Ron Lowry, Dawn and myself.  It was morning. Creativity was sparse.

Thank goodness for Suzanne. She created a wonderfully simple introduction:

We're here,

We're great.

We're the Class of '88.

We met President Jackson and cheered.  Several of us alumni complemented President Jackson on her work renewing Rensselaer and her efforts to reach out to us graduates.

A few of us took an unofficial tour of the campus.  It is truly beautiful now.  The approach has been rebuilt.  The football field and surroundings are gardened beautifully.  The new buildings are stunning. We even took an unauthorized tour of the new, stunning EMPAC. (Getting yelled at by a voice of authority took me back a score of years...)  Late afternoon, Dawn brought out some wine, cheese and crackers that we shared them beside the new fountain in front of Warren, Sharp and Nason halls.

Our wonderings led us to meet a few graduates of other years.  Robert Vienneau, ’83, helped us investigate the LEGO program and Becky Matheus, ’78, encouraged us to … well, no reason to get her into trouble too.  We also bumped into more ‘88ers Jesse Edelman and his wife Lisa and Andrew Wasielewski  and his wife Mimi.

Here’s the latest news on the class of ‘88:

Suzanne Cano Meeker began working at GE for the Renewables Quality department as the Regulatory Product Compliance Leader in Schenectady NY back in March.  Her commute is a fabulous 10 minutes. After so many years in health care and small business, she says she’s very pleased to be working for a major corporation once again.  The position is very challenging and the easy commute helps her manage the soccer/baseball/football/ballet carpooling after 5 pm!  Suzanne says she had a great time at the reunion. Her kids Billy, 9 and Sierra, 8 really enjoyed the LEGO robotics program and playing in the pool. Her husband Bill had fun at Casino night.

Kris Edwards-Provenzano has recently been awarded the T-Ball Mom of the year award for her ability to keep nine six-year olds in batting order. "I’ve discovered that Benadryl and leg shackles work best,” states the 23 year old mom (Yeah 23!) of two boys, 14 and 6, “I tried cattle prods and whips, but those helmets and bats provided too much protection.”  In addition to driving throughout rural PA for games, scouts and boys shoes, Kris finds time to work for the National Park Service as planner, designer and construction manager at the Delaware Water Gap National Recreation Area that oddly enough is actually located in PA and NJ.  In her free time she enjoys power naps.  Her goals for the future involve surviving motherhood and eventually relocating west of the Mississippi.

Ron Lowry is the manager of SeaTech Bioproducts Corporation, a manufacturer and supplier of marine products and by-products for use in the agricultural, cosmetic, pharmaceutical, and chemical industries. Ron earned his Master of Healthcare Administration from Duke University in 1990.  His company enables (and necessitates) a fair amount of travel nationally and internationally as he does business in Central and South America, North East Asia and China, South East Asia and India, Western Europe and North America. Ron lives in Boston, MA right near beautiful Fenway Park. He stays appraised of the successes of the RPI football program

Andrew Wasielewski is a practicing attorney in Las Vegas, NV.  He earned his Juris Doctorate at McGeroge School of Law in California and now works for the Wasielewski Law Firm.  Andy briefed President Bush after the US captured Saddam Hussein.

Jesse Edelman and his family have settled in San Antonio, Texas, after several years of traversing the country. Jesse has his own company, ArchPoint Consulting, which solves clients’ growth challenges by developing strategies and execution plans to win in the marketplace. ArchPoint Consulting’s primary client focus is consumer products manufacturers   Jesse and his wife Lisa love being back in Texas.  He says, “While I am enjoying life as an entrepreneur, my greatest joy is spending time with our 2 kids, AJ, who is 9 and Lena, who is 3.”  Jesse came all the way from Texas for the reunion and encourages more people to attend our 25^th (or one score and a quarter) in 2013. 

Rob Lackey and Christine Burkhardt are both specialists in Family Medicine employed by the Wellspan Medical Group.  Rob recently expanded his role when he became an Ambulatory Informatics Specialist and uses his engineering background in implementing the group's electronic health record across the group's 300+ physicians.  They have 2 children – Alexandra, age 13 and Robbie, age 11.  Since Alexandra is heading to high school this fall they thought it would be a good time to show her a college campus.  Chris says “The kids really enjoyed exploring the campus, but they could not believe it was as cold as we told them since it was extremely hot for Troy during the Reunion. We enjoyed attending the Reunion in June.  We had not been back to the campus since the year that we graduated.  Some areas of the campus looked the same but there were many new changes that we enjoyed seeing.  It was also nice to meet some new people who we graduated with, but had never met before.”  Chris and Rob have lived in York, PA since they got married in 1992. They can be reached at rlacke01@comcast.net and cburkhardt1@comcast.net .

Jem Anderson and his wife Gretchen live in Front Royal, VA. Jem works as a Systems Engineering Specialist and engineering supervisor for BAE Systems.  He left Air Force active duty in 1999 and was recalled to active duty in 2001-2002 and in 2008.  In fact, Major Anderson was in Iraq with the Army’s 360^th Civil Affairs Brigade at the time of our reunion. Jem says, “Best wishes to the Class of 1988!”

Paul Grous and his wife Beth live in Franklin, MA. Paul earned his MBA from Babson College Olin School of Business and works as an Enterprise Architect at Perot Systems. Paul and Beth have two daughters Jennifer, 5 and Caroline, 1.
Alan Brill lives in  Kansas City, MO.  Alan earned his MS in Biomedical Engineering from Worcester Polytechnic Institute.  He has 2 patents for angioplasty catheter designs while working at SciMed Life Systems/Boston Scientific. Alan currently works as a Delivery Consultant for Cerner Corporation. Alan also is a member of his local Community Emergency Response Team (CERT).   He has 2 sons ages 8 and 10. Alan is still in touch with RPI alums Keith Carangelo, Ken Daniels, Mike Smith and Dennis Begley.

James Gilbert lives in Niwot, CO. He and his wife Michele McGovern have 2 daughters, Madison McGovern Gilbert,10 and Kendall Melanson Gilbert, 7.  Jim earned his MBA in Finance and Entrepreneurial Management from the Wharton School in 1997.

William T. Cooley and his wife Janet live on Hanscom Air Force Base in Lexington, MA where Bill is the Commander of the 350th Electronic Systems Group. They have 3 daughters Kelly, Katherine and Rachel. Bill earned his Ph.D.in Physics at the Air Force Institute of Technology and a Masters in National Security at the National War College. The highlights of Colonel Cooley career include his service in Kabul, Afghanistan, in Germany and at the Pentagon. Bill runs 26 miles and 385 yards – and presumably shorter distances – for fun.

Ann Noyes McGuire lives in Bloomington, MN.  She and husband John have two sons. Jack, 8 and Michael, 5. They have an great addition to the family – for one year only –  an AFS exchange student named Korn from Thailand. 

Christine Bachrach (née CJ Nivala) says: “After getting my Masters at UC Berkley, I went into healthcare eventually becoming a Principal at Navigant Consulting.   I got tired of traveling all the time, so joined HealthSouth Corporation 4 years ago.  Last year I was promoted t o Senior Vice President and Chief Compliance Officer.  I’ve been married 14 years to Yoav and have 2 children: Sivanne, 8, and Aitan, 5.”

Robert Rottenbucher works as a Chief Structural Engineer for the City of Boston (Public Works Department).  He is responsible for city-owned bridges, tunnels, retaining walls and landfills.

Christine Bennett (née Lioni) lives in Marlboro, MA with her husband Andrew and their children Michael, 9 and Matthew, 7. Christine worked at Digital Equipment Corporation (later Compaq) from the time of graduation in 1988 until 2000, when she left paid employment to become a stay at home mom. Christine volunteers at the American Cancer Society and works on her jewelry business part time.  She stays in touch with the women of Pi Beta Phi.

Sidharth Bhargava lives in Thousand Oaks, CA with his wife Vaishali, daughter Sona, 7, and son Ajay, 5.  Sid earned his Ph.D in Electrical Engineering from the University of California, Santa Barbara.  He works for Teledyne Imaging Sensors where he is the manager of the Detector Array Processing Group. 

George M. Kappaz and his wife Amarie lives in the Washington D.C/Maryland area. George is the President and Chief Executive Officer of Comsat International, Inc a leading global satellite and terrestrial communications company.  He previously founded KMR Power Corporation, a global owner/operator of power generation plants.  KMR Power was successfully sold in 2000. George has four children Alexandra Delores, 15, Michael Fitzpatrick, 13, Katherine Elizabeth, 2 and Patrick Francis Xavier, 1. He stays in touch with Bryan Mitchell.

Erwin Karl currently lives in a farmhouse in Jefferson, NY with his girlfriend and two dogs. He has lived in Africa and Europe. Erwin enjoys renovating barns and houses with mostly recycled material. In addition to working his farm, Erwin is a freelance writer.  He has published non-fiction, poetry and short stories in the US, Japan and South Africa. Erwin is a Trustee, Secretary for the Stamford Village Library Association, an member of the Catskill Community Players and the Open Eye Theater.  He is still in touch with alumni Juan Escobar and Dave Hale.

Rich Siegmund is living in Austin, Texas and working for IBM (still). Rich began his career with IBM in Poughkeepsie, NY, and is currently a manager of a chip design group that develops server processors. Past projects of interest at IBM include working on the processor chip for the Xbox 360.  He has a 10 year old daughter and spends all his free time investing in real estate. Rich stays in touch with Gwen Owens.

Kirk Schell was in the news. He is Dell’s Corporate Director of Marketing for Dell Computers’ China Design Center in Shanghai. Kirk’s team will be responsible for product strategy, business development and product management for Dell’s portfolio of business products worldwide. Prior to Dell, Kirk earned a degree in Business Administration from the University of Michigan. He served in the US Navy for 7 years where he had multiple shipboard leadership position in the U.S. Navy Nuclear Power Program.  Kirk and his family will live in Shanghai on a two-year expatriate assignment.

Speaking of Shanghai, Steve Mushero left Shanghai for the Olympics and visited with friends and family along the east coast. Ron Lowry, Dawn McGee and I caught up with him at the Sunset Bar and Grill. Of course, we tried their buffalo wings.  I got a picture of the 3 of them, but cut off a bit of Ron’s head. (What can I say – Steve and Ron are much taller than I.) Bill Miller, Ron and Steve got together the following night.

Making new friends and becoming reacquainted with old friends, I was struck by how terrific my former classmates are and how interesting and diverse our lives have become.  The twenty years does look great on us.

More updates on the class of ’88 in the next edition.  If you’d like to let your classmates know more about your life, please write to me: Bonnie Rind (née Woronoff) Bonnie@BonfireDA.com

Class Notes - June 2008

Hey everybody, by the time you read this magazine, our 20^th reunion will have come and gone.  I hope we had fun!  I know we look great. 

Congratulations to my old friend Kevin King!  Lieutenant Commander King is recently retired from active service in the Navy after 20 years. He most recently served at the Naval Aviation Schools Command in Pensacola, Florida.

Eitan Yudilevich (Ph.D. '88) is the Executive Director of the Binational Industrial Research and Development Foundation (BIRD), established in 1977 to fund joint U.S.­Israeli teams in the development and subsequent commercialization of innovative, non-defense technological products from which both the Israeli and American company can expect to derive benefits commensurate with the investments and risks. Since its inception, BIRD has approved 776 joint high-tech R&D projects through conditional grants totaling more than $255 million. Products developed from these ventures have generated direct sales of $4.5 billion. Recently, BIRD has emphasized issues related to sustainability, such as renewable energy and water technologies. In addition, Eitan leads a tri-national fund named TRIDE, which supports joint U.S.-Israel-Jordan projects. Eitan was recently in Troy to give a talk for the New Horizons Speaker Series, sponsored by the Rensselaer Office of Entrepreneurship. Eitan, who is originally from Chile, lives now in Karmiel, located in the Galilee, Israel. He is married to Bruria and they have three children: Gali (1976), Ori (1980) and Dan (1986). Dan was born in Troy, while Eitan was studying at RPI.

Michael Shamma (B.S. '88, M.S. ??) was recently promoted to the position of Regional Director for Region 2 at the New York State Department of Transportation.  Mike is responsible for the operation and maintenance of the transportation infrastructure in the beautiful Mohawk Valley region.  Mike lives in New Hartford, NY.

Congratulations to Sharon Tasman and her lucky groom Mark Prysant.  Sharon is a counsel with Hogan & Hartson in Washington, DC specializing in technology-related legal transactions.  Sharon sent us her wedding update via the RPI alumni website:
"We had the whole big wedding planned, but sanity got the better of us and my fiance (now husband) Mark Prysant and I decided to elope!  Six phone calls to the Bellagio Hotel in Las Vegas later, the whole wedding was planned - Rabbi, chuppah, flowers, photo and video! On Friday, July 13th (a lucky day for us) we got married with three friends as witnesses, and thanks to the Bellagio's live webcam option, the rest of our friends and family around the world could watch the wedding live!  It was great - we were the only couple getting married that day since everyone else was being superstitious so the hotel was extra attentive.  The only drawback?  The 110 degree heat when we took photos outside by the hotel's lake!"

Steve Mushero (B.S. '88, MBA '90) is living in Shanghai where he is the CTO of Tudou.com, the world's largest video web site. Before that he served as CTO, CIO, and/or Chief Architect of a variety of Silicon Valley and global companies, and worked on projects for the World Health Organization and Grameen Bank's Technology Group.  An avid globalist, Steve published a 2007 book on Globalization and speaks both Japanese and Chinese.  He's enjoying life in China and traveling whenever possible. He can be found on the web at www.SteveMushero.com

Jeffrey N. Brown (MBA ’88) was recently promoted to Chief Administrative Officer at Webster Financial Corporation.  Jeffrey is responsible for Webster's information technology, operations, human resources, communications, public affairs, strategic planning, facilities and Internet functions. Prior to joining Webster, he held several senior management positions with the former Fleet Financial Group.  Jeffery is a member of the Advisory Board for the Yale School of Management Center for Customer Insights. He serves on the Board of Trustees for The Bushnell Center for the Performing Arts and on the Glastonbury Education Foundation Board. He is president of the Harold Webster Smith Foundation and is a director of Webster Insurance. He is also a representative for Webster to the Financial Services Roundtable.

If you have read this class update then you obviously want to know more about your old friends.  Well, your classmates want to know more about you too. 

We want to hear the usual (and incredibly important) facts such as where you live and work, married/kids etc, and we also want to hear something about you that reminds us of you. (Examples: Still carousing/no longer carousing; still in engineering/no longer in engineering; still fighting for world peace/fighting for peace in your household; building the backbone of the Internet/ working on a vaccine for malaria/ helping to promote spam in India/ just working your tail off.... ) 

Send me your news or even a “hello world” email and I’ll help you with the rest of the text. Bonnie Rind (nee Woronoff), bonnie@bonfireda.com

 

Class Notes - Jan 2008

Shortly after our RPI graduation in ‘88, a group of us living in Boston joined on a quest to find the best Buffalo wings in Boston.  We happily settled on the wings at Tom’s Busy Bee Pub in Watertown, MA and became regulars there.  Our weekly wings and beer dinners at the Busy Bee soon grew to include our co-workers and friends, and eventually our spouses.  Our wings tradition lasted 18 years until the Busy Bee closed last year.  So we’re once again searching for the best Buffalo wings in Boston…. Meanwhile, the wings crowd and other friends from the class of ‘88 thought we’d post brief updates on our lives since we left Rensselaer.
 
Phil Hill (BS ’88, MS ’89) has his own consulting company, HBO Systems, working directly with universities on strategic planning.  Phil began his professional career in the US Air Force before moving into the private sector.  Phil and his wife Emily have 3 daughters Hillary, Betsy and Olivia who have been home-schooled for the past year and a half.  While home-schooling is a lot of work, the whole family is enjoying the change.  Emily is yearning for a lunch at Holmes and Watson. They currently live in North Carolina and will be moving to San Francisco this fall. Phil and the family are looking forward to our 20^th reunion next year.
 
Keith Jennings works at Partners Healthcare / Massachusetts General Hospital in IS Management and Planning.  Keith served in Operation Dessert Storm where he was stationed in Saudi Arabia and in Hungary for the peacekeeping efforts in Bosnia.  He and his wife, Renata, live in Boston where they have a fantastic view of the city, particularly from their rooftop deck.  Keith recently organized an alumni tour of the Deer Island Water Treatment Plant. The plant was an important part of the effort to clean up Boston harbor.  The tour was quite interesting and everyone returned safely and as clean as they arrived.  Keith is a ‘wings crowd’ regular.

Glenn Kaufman (BS ’88, MBA ’90) is the head of the Global Business Office at Citigroup Technology Infrastructure.  Glenn has worked in the financial services sector most of his career, working for AT&T, Banker’s Trust, JP Morgan and Deutsche Bank before Citigroup. Glenn and his wife Rachelle (Albany '89) live in Suffern, NY with their 2 children, Lauren 11 and Danny 7.  He enjoys playing video games with his children and set up an XBOX 360 Guitar Hero tournament for the 30 kids at Lauren’s 11th birthday party. Although Glenn feels left out of the wings/beer events in Boston, he makes do by serving up similar fare whenever any of the '88 grads visit.

Valerie Northrop (BS '88, MS '91) is a manufacturing engineer at Cambridge, MA based start-up E Ink Corporation.  She started her career at GE before moving to Polaroid in Norwood, MA.  During her 10 years at Polaroid, she moved from engineering to management to technical sales.  She then took some time off to regroup and recharge.  She spent her sabbatical traveling to Hong Kong, Scotland, Norway and the Western United States, doing interior painting and finish-work, and singing with local a cappella and theater groups.  Val can be reached at valeriecn@msn.com.

Dawn McGee (née Mertzer) recently joined MapleWorks where she works as a Business Development Manager.  Dawn’s career has focused on telephony and mobile communications.  Beginning as a support engineer at Wang, she became a support manager at Aspect Communications, moved on to product management at Nokia, and worked as a sales manager at TomTom.  Dawn indulges her love of good wine and good company with a side-business holding private wine-tasting parties, which she plans to turn into a full time career in the next few years.  Dawn and her husband Mike have an active 3 year old son named Spencer.  They live in Woburn, MA.  Dawn is another ‘wings crowd’ member.  She can be contacted at: dawn@ttvineyard.com.

Zoë McLaughlin is currently working for Technorati.com in San Francisco.  Zoë has lived and worked in Japan three times, first as a design engineer for Honda Research and Development, then as an Engineering Liaison for Kelsey Hayes and later as a Technical Support Manager for PTC.  She speaks fluent Japanese.  She has also lived (more briefly) in Ohio – where she escaped from a fire in her apartment – and Massachusetts before returning to her hometown of San Francisco.  Zoë owns a beautiful Victorian house that she shares with her 2 Labradoodles, Koko and Sasha.  Zoë has attended some of the San Fran alumni chapter functions, but hasn’t met too many RPI grads in the area.  She can be contacted at: zgeek3-rpi@yahoo.com.  She also writes the blog http://spectecdis.blogspot.com.
 
Bill Miller recently joined Juniper Networks after many years with the company that began as Wellfleet Communications (founded by ‘69 grad and Board of Trustee Paul Severino) and eventually became a part of Nortel Networks.  Bill and his wife Carole have two rambunctious boys Zach and Drew ages 7 and 6 respectively. They live in Groton, MA.  Bill spends his free time playing with his kids – often helping them build something – and doing woodworking projects.  Bill is an anchor of the ‘wings crowd’.

Bonnie Rind (née Woronoff) has her own consulting company, Bonfire Development Advisors, working with technology organizations to ensure the development staff builds successful products.  Bonnie began her career as a programmer, became a designer and eventually a product manager.  Bonnie has twice taken time-off from the professional working world, once to ski for a winter at Winter Park, Colorado and once to write a mystery novel.  (It's unpublished.)  Bonnie and her husband David live in Newton, MA with Alena, their affectionate 1 year old daughter, and Stella, their sleepy 11 year old Newfoundland dog.  Bonnie is a ‘wings crowd’ member.  She can be reached at bonnie@BonfireDA.com.

Kristin Stadelmann, our current chapter president in Boston, lives in Boston and runs her electrical supply company, Central Electrical Specialty Co. She also works part-time as a crew member of the Turner Motorsport auto racing team, traveling around the country to many different road courses throughout the season. Kristin volunteers weekly at the Children’s Hospital in Boston and helps fundraise for the Boys and Girls Club. She has traveled extensively internationally over the years and is recently returned from the America’s Cup in Valencia, Spain. Kristin lives part time in Islamorada, FL where she fishes, kayaks and scuba dives. She recently ran the Vancouver half-marathon with Wendy Kane ’88 of Portland, OR and accompanied Wendy and Sue Taylor ’88 on a trip to Scandinavia to run the Copenhagen marathon.  Kristin can be reached at kristin@stadelmann.com.
 
Every so often – particularly in our younger days – we’d have wings on the road.  Sometimes, the road was the Mass Pike leading us back to RPI to catch a hockey game, see friends, or even just for some nostalgic enjoyment of Sutter’s Buffalo wings.  Since writing these updates, we’ve begun chattering about a ‘wings on the road’ to Rensselaer for our 20^th reunion…so, maybe we’ll see you there.

That "Ah-ha" Moment!

Here's a simplified *before* personas and *after* personas scenario. Download the pdf.

Background:

You and your team are responsible for developing the next generation of WhizApp’s Office Management software, an established brand for office management and accounting software.  WhizApp OM is used in accounting, finance, communications, inventory, payroll and other functions. 

WhizApp OM has millions of users in diverse business environments.  WhizApp would like to be bigger than SAP, but hasn’t managed to be that successful yet. WhizApp markets themselves as offering 90% of the functionality of SAP at 20% of the cost.  In reality, they offer and plan to continue offering less functionality than that. Their goal is for the users to forgive the missing features as inessential while attributing their absence to 10% that makes the software more cost effective.

Obviously, this is a big challenge. How does one determine the “less important” functionality?  Existing users regularly request new features and ask for changes to existing features. Your current interface is old, yet you secretly fear some of your users’ ability to handle significant changes to the application.  To grab more of SAP’s market, you need to add functionality, some of it to delicate parts of the existing product. Furthermore, you have requirements to add new components – such as tracking and logging – to satisfy internal business demands, though these functions have not been requested by any user. 

Problem Summary:

Your task is to develop and deliver a major overhaul and update of the WhizApp OM system in order to keep your company vital and to deliver new, highly competitive features, as yet undefined.

How do you decide what functionality to provide and with what priority?  What features are out of scope? What is the presumed user’s skill level?  Maybe there are features you can remove?

In a nutshell: What will make your users want and be satisfied by the system?

Who Are the Users?

WhizApp OM has millions of users.  You’ve met a handful at customer visits, user conferences and their visits to your office.  They seem incredibly different, and seem to have very different demands for our system. 

Here are a few of the users you’ve recently met:

1) Amy Prott coordinates and oversees payroll, employee orientation and benefits at a large law firm. Her demands on the system can be intense and she has to know she can trust WhizApp OM to work properly.  She says she wishes WhizApp were more like SAP.

 

2) Carmen Bembaron’s work environment isn’t enviable. He handles finance data entry and some analysis.  He relies on a rather old computer for all aspects of his work. He doesn’t create or refer to paper much or work with other people.  Carmen does his job each day. He doesn’t care much about what comes of the data.

3) Sandra Nygun and James Randell work for a large office development firm in New York.  They work in the finance department and often collaborate to prepare reports for their Director. Sandra and James know they are competing with each other for the next promotion.

4) Archie Blair works for an 80-person high tech software company with offices in various parts of the US, plus sales offices in the UK, Germany and Japan. Archie works in a remote office, performing multiple roles for his company.  When he’s in his office, he mans the help-desk, writes white papers, supports sales calls and manages the accounting for his office.  On the road, he does sales supports.  Archie is upwardly mobile and is careful to make a good impression with customers yet willing to create havoc in the office.

The Conundrum:

What features do they need? Where’s the commonality?  How do we understand for whom to build what functionality?  How do we avoid building features for one user with the skills of the other?  How do we prioritize our list of features?

Has thinking about the users improved our clarity? Have they helped us define the system?

The Solution:

Take a step back and assess the problem for the standpoint of WhizApps’ goals, core strengths, the needs of its diverse user base…. Look to create a realistic archetypal user – a persona – who would lead your company to build a product that will appropriately satisfy that diverse user base.

For the WhizApp OM product, “Pauline” is that persona.

"Pauline" works for a retail franchisee.  Her bosses – a married couple who she considers friends - own several of the franchises in the state.  "Pauline" handles accounting and payroll, and ensures the businesses meets all legal and franchise requirement. Her office is modern but basic. "Pauline" is a capable computer user, but not a techie. She trained as a legal secretary, and took her job based on her friendship a friend of the owners.

"Pauline" considers her work-life to be a continuation of her social network and friendships.

"Pauline’s" goals are:

• To earn a living.
• To keep the office running smoothly.
• To help the company thrive while ensuring it survives.
• To be viewed by her bosses and the other employees as a friend and equal.

When building software for "Pauline":

• Realize that her work is:
  • Independent,
  • Non-collaborative
  • Reviewed
  • Depended upon
  • Cost conscious
• Focus on general business features, for both small and larger companies to meet, as her bosses and the company has the requirements of both.
• Build her interface to focus on data collection and analysis. While she doesn’t use reports to do her job, she creates very polished reports for her boss to provide to the franchiser.
• Plan the software for current, not cutting edge, technologies.  "Pauline" can upgrade if necessary.

Persona Benefits:

Now that you know “Pauline” represents your primary persona, you can probably see how she meeting her needs will also meet the needs of the other users in her without the distractions and confusions caused by their differences. Pauline’s environment causes her to have the demands of a big corporate environment (the franchise) and the demands of a Ma & Pa shop (the franchisees).  Her work is diverse, having collaborative components (working with her bosses/friends) as well as significant data entry and data analysis needs.  Franchisees typically watch costs carefully; yet understand that significant capital expenditures are a part of being competitive. 

The only need "Pauline" doesn’t address well is a possible need to have access to the system while traveling.  If such as need does exist – that would require further study on Archie Blair and similar users, those needs and skills could be met with a secondary persona.

This is an example case.  In the real world scenario, a company would surely require at least one secondary persona and perhaps a negative persona to help marketing, product management and development know what to build and how. The great benefit of personas is that - rather than trying to corral the demands of the millions of users – they are a simple tool that guide your team to build products that meets your users’ needs and skills, and your company’s goals.

Ah-ha!

Is Your User Dangerously Elastic?

We all imagine a user when we build our software. Have you ever committed your imagined user to paper (or bytes)?  If you haven’t, try it now. 

.... <thinking>
.... <writing>

Were you able to do it?  Congratulations. Many times, I can’t even get an initial description to paper.

Now, how does he look?  Did you describe:

• The reasons he is using your product or feature?
• His work or play environment while using your product or feature?
• The skills he has with and brings to your product or feature?

Is your user robust, realistic and consistent?  If so, you obviously know a great deal about your user base, so read no further.  If not, you’ve likely got one of two problems:

1. You don’t (yet) know your users, and are guesstimating, or
2. You do know your users, but having segmented them according to need and skill.  This is called an “elastic” persona, where the user is stretched to meet qualities that are simultaneously impossible. 

Imaging building features for advanced users with an interface for the relative novice; expending a tremendous effort to make your product localizable when the users (foreign and domestic) will only ever use the English; or spending too long building the primary user’s interface when that user’s time is cheap (and she has no influence over the buying decision).  These are 3 elastic user situations I’ve encountered just this year.  They were all a waste of effort, time and money.

If you’re guesstimating your users, I recommend you read this posting on improving your user image or persona.  If you have elastic personas, you may simply need to carefully divide the users according to their needs and skills.

Let me know if you have any questions.

Work/Life During the Dot Bomb

Have you read “And Then We Came to the End” by Joshua Ferris? 
It’s (significantly) the book I tried to write during that era, but far far far better than I could have done. It’s amazingly well done. Despite being a book about work, “And Then We Came to the End” is a riot. And it’s uplifting.

Its about people in the marketing department a marketing firm getting crushed by the recession.  It seems that the work life of a ad agency creative is quite similar to a programmer’s work life:
All that work just to get to the work; the work of making work interesting; the work that goes no where; the changes that make the previous work irrelevant; the work to prime the pump, plus work relationships, biases, prejudices, jealousies, strati and perspectives that change in less than the blink of an eye.

Getting people to want to read about the workplace is a tough nut to crack. Joshua Ferris has made a creamy butter of it.  (He even added a character who is trying to write an interesting workplace novel.)  We all spend too much time at work. This book helped me appreciate why we do it.

A Moment of Horror

I met a friend for drinks to casually brainstorm on her company’s brand image. I sat down, ordered a beer, some appetizers. We chatted.  Eventually we got to the subject of the brand. 

She handed me a typewritten paper with notes written over the text in places and in the margins. Her hypothesis is that her new brand should be created like a persona.  This is akin to my conceit that product should almost be it’s own persona.  (Hence the name of this blog.) I respect my friend a lot.  She has of integrity and professional follow-though on her idea.  She’s currently working for a B2B consulting firm.

So finally, feeling the drink just a bit, I looked down at her page. 

To:
·    Men, aged 30-59, who are ambitious/resourceful/efficient/punctual
·    Who presently spend a lot of their time in their car, generally enjoy driving, and often find themselves in unfamiliar territory or unforeseen situations, and ..

The page swam beneath my eyes.  I felt myself flush.  Ugh.  Wrong. Horrible.  Wrong.. Ugh.

I said, “Um..”  Then, I looked back down at the page, there was something about those handwritten notes….

Ohh. I exhaled.  The notes were good.  The notes concerned buyers concerns and needs. Ohhhhhh.  My friend was using an old B2C brand statement as a template. Whew.

What if I don't know my User or Buyer?

A few days ago, I gave a talk on Personas and Agile Programming. My audience was a mixed group:  Programmers - Agile & not, implementation folks, support people and a couple of company VPs. The talk was a bit less 2-way than I would have preferred, but that tends to happen when VPs are in the room.  Overall, the group was very receptive and they appreciated the inclusive nature of Personas.

The company has one solid, legacy, product line. They've begun creating new products for users in domains very near their area of expertise, but not within their expertise. Put another way, they have perceived a pain, or maybe just an opportunity. However, they don't know their user or the conditions that will drive a purchase.

"Should we build a Persona?", they asked. Yes! Absolutely! Of course! 

Here's how to proceed when you have access - even just peripherally - to your future users and buyers:

1. Build a straw-man Persona.  I don't love ad-hoc Personas, but they're a perfect starting place. Each lead should put to paper their biases, guesses, best thoughts on who will be using and who will buying the new product. Then swap the papers. 
2. Learn from the other user and buyer experts within your company. You've looked at the other guys straw-man persona. Talk to someone in Support. Talk to Sales. Once you've seen that your view of the users and buyers is different from other experts' views, talk out the differences. What have you learned? How would your new product differ if the user or buyer were like her straw-man?  Can you build a new straw-man persona? If so, do it.
3. Visit the users and buyers you do have access to.  Since the users and buyers of your current product are your leads to the users and buyers to the new product, grab those leads. Go visiting. You don't have to say much or anything about your new product line. Just take a look around while you're there.  Do you see anyone who looks like your persona? Did your imagined persona work in an environment like this? I bet s/he probably doesn't. For some reason, we all idealize, generalize, overlook. Now you can make very important improvements to your straw-man persona.

Are you done? Sadly, no. But you do have a somewhat refined ad-hoc persona. Not as good as real, robust persona based on market research and deep knowledge of your user or buyer, the straw-man ad-hoc persona is very useful. S/he will ensure everyone on the team moves in the same direction - making your team more cohesive and efficient - and everyone on the team will immediately recognize when true user and buyer information shows up that grows or alters the persona.

Creating, refining  and working with ad-hoc or straw-man Persona takes guts.  It requires the management to admit to themselves that there are some things they just don't know. 

Marketing Jobs or How to Assign a Product Owner

Has everyone noticed how many open marketing jobs there are out there right now?  Apparently, in addition to being a country of blackjack dealers and security guards, we're a country filled with something to sell - if only it were pitched right.  Such is the current - hopefully modest - recession.  These ads for marketing people are  for VPs and entry level, not too many in the middle.  It seems that some of these companies feel the need to revamp their overall approach while others figure more marketing is better marketing.

Applying this experience to the world of software development, maybe its not so different from boom times.  Everyone has a product to build/ is founding a company/ is a VP of something development related.  In a boom, entry level programmers are "senior" and the number of engineers on a project is the primary indicator of its success. 

Right now, software development professional are doing pretty well.  The work seems to be there (when you finally get past, or manage to avoid, those automated technical interview test programs). The current trend toward Agile development methods is making our business vastly better.  Agile gives everyone an opportunity to build a success. Agile also exposes everyone.

The toughest part of successfully implementing Agile may be successfully finding the "product owner" on an Agile team. It's typically a product manager who gets the job.  As the product owner, s/he represents the company's executives, visionaries and high-level decision makers on the team.  As product owner, s/he must know, very specifically:

• Who are the largest, fastest, and most devoted group of buyers, and
  
• What are their skills, goals and desires?

i.e. Tell us developers our market; tell us what will motivate a purchase; and describe the true needs of our users. 

Can your product owner do that?  Is there anyone in your company who can?  Does the answer remain constant for more than a month? 

Agile exposes everyone.

Managing Your Power Users with Personas

When a power user makes demands, he is often asking for features for:

• Himself
• The people he influences, guides, manages or trains
• His plan in the future of your product

Your company may decide to change their product due to this one user's demands or your company can know their product, market and vision well enough to meet the aspects of the power user's demands consistent with your product's best direction while deferring those that are not.

Well-designed personas are a terrific tool for helping everyone in your company understand and make good judgments about your product and it's direction.  As mentioned in "What Are Personas", a product’s set of  personas may include the following:

• A primary persona who represents of the primary user of each major interface. The primary persona may not actually represent the majority of users, rather he represents the skills, needs and goals of the primary interface. Not based on any individual, the primary persona must be a robust archetype of real human beings.
• One or two secondary personas who represent additional users of the each major interface, with with differing needs, skills and goals of the primary persona. The secondary personas also must be robust archetypes of the user base.
• One or two negative personas who represent requests for needs, skills or goals the interface is explicitly NOT to address. The negative persona can be a stereotype of a user. How well do you need to know a domain you don't address? Just well enough to recognize it.
• One or two buyer personas who represent the buyer's needs, biases and goals. A buyer may or may not be a user of the product.

Let's look at a simplified automotive example.  Let's assume our company, BR Motors builds high performance minivans. 

Our primary persona might be Lynn.  She's a small woman (5' tall) with 2 children still in child seats, and a St. Bernard dog she likes to take with her on trips small and large. Previously, Lynn drove an Audi sports sedan because: it had a high safety rating - including in non-us offset tests - accelerated well, handled like a dream, and had 4 doors for easy open and closure (remember she's tiny).  The price of the Audi was high but acceptable.  She planned to keep the car forever, but was frustrated because the care broke frequently and expensively.  She has vowed never again to buy an Audi.  BR Motor's minivan will become her primary vehicle.  She's dead set against buying a minivan and hopes to find a high performance station wagon to meet her goals.

Our Secondary persona might be Lynn's husband Michael.  Michael is tall.  He also likes a car with good pickup and handling. Safety ratings and also inherent safety sense of a car are important to him, so he demands good visibility from a car. He will drive all of the family trips because Lynn's driving frightens him. Michael thinks the minivan is cool because it can carry almost anything.  While he won't admit it, he's clear that he doesn't ever want to become the primary driver of the vehicle.

Our Negative persona might be Mack.  He wants a tough and tough looking vehicle for his bricklaying business.

Non-obvious, empowering product facts we can intuit from these personas are:

• Our minvan should clean easily (similar to the interior of a kitchen).
• In and out of the minivan should be easy - for a small woman, a tall man, and a large old dog.
• The minivan should reconfigure drivers easily.
• The minivan should subtly remain the woman's domain.  (How to accomplish that is tbd)
• If the demand is for industry - even for dog sitting - that's not the direction BR Motors minivan is going.
• The minivan must better address the needs and goals of Lynn's family than the station wagon or you won't have a sale.

It's important to be aware that a product's real users - especially the power users - may exhibit the qualities of more than one persona.  For example, suppose we have a user named James who has purchased two BR Motor's minivans for his rural veterinary clinic of 5 people.  He requests the entire vehicle - including the rear - to more disinfectable because he has truly filthy equipment going back there. He'd like better shocks and a higher ride for the dirt and mud roads he travels.  He bought the car for its reconfigurability, flexibility, size, price, and handling.

Using the personas, we can see that James is significantly using the minivan as a Mack.  We can't just discount his requests.  He's a significant buyer and a power user, but we can and must look at his requests to see which will be valuable to Lynn and Michael and which for Mack.  (I can see us making the main cabin of the minivan even more cleanable and perhaps doing work on the reconfigurability of the vehicle, while largely putting aside James' requests.  We know our market.)

With personas, everyone in the company will:

• Naturally organize and internalize the demands of the power user
• Understand the priority of each request (high, medium and not)
• Implement the best features with the appropriate interface. 

Personas are a great power tool to prevent a Product Management Development from chasing sales and from building a product that only one person (says he) will buy. 

Intuiting Your Audience

I’ve been meeting with VP and Directors of Development and Product Management of – typically – well-funded, mid-stage startups.  It’s clear to me that these leaders who set the direction of the product are not getting enough time with their customers and prospects. It’s the typical product management difficulty. They want to spend the time with their users and buyers, but can’t find the time to do so. There are just too many other pressing responsibilities; too many fires to fight. Instead these product and development leaders intuit their users and buyers. If you are doing this, my advice is to be sure to:

• Intuit the users and buyers based on reality, not on guesswork
• Ensure the staff have a common intuition of the product’s users and buyers (so the work is at least consistent)

Here’s a quick example:  A, a User Experience expert, inherited responsibility for a relatively technical software product that was OEM to (I’m not making this up) Intuit. Intuit’s users weren’t happy with the user experience of the product. Intuit considered severing the OEM deal, but gave the company a chance to address the issues. 

A began calling users.  It turned out that none of the users A spoke with were technical.  While ideally the user would be technical – even a sys admin, actual use of the product had fallen to an administrative assistant, a marketing person, etc.  Based on more research, A created a robust persona for the UI programmers. The programmers, in turn, quickly modified the interface to meet the needs of the true product users rather than the assumed users. The big OEM deal with Intuit was saved.

Corporate Grief: Could This Be Your Company?

I recently had lunch with a consultant friend recently to share ideas and experiences.  I talked about some of the unexpected (to me) elements of blogging, my recent work and a couple of good prospects.  She told me about her her current client. 

Despite the intelligence and friendliness of each individual, as a group, the client employees were so defensive, ineffective, and frustrating that my friend and her staff began identifying them by their stage of grief.  Apparently, her last meeting was with Anger, Denial and Depression.

My friend said she was conflicted, but essentially eager for her current job to finish up.  She, at least, had reached Acceptance.

Replace This Engine: A Persona Story

WhizApp, the company I introduced Personas to a few years back, reached the business decision (due to financial & legal pressures) to replace a 3rd party engine in their DeskTop product-line with a similar, but entirely different engine from another provider.  The project initially stirred all sorts of emotions and opportunities within the company:

• Marketing thought it a sad waste of money and energy to gain very little additional product or market features
• Product Management agreed with Marketing, while fearing the product would lose functionality
• Development thrilled at the idea of replacing an old, archaic piece of software with one that was more modern and more functional.

The company treated the engine replacement as a relatively pure development project.  Take out the old and put in the new.  Experts in the subject matter were hired to work on the project.  Time and customizations from the new engine provider were part of the deal. Original estimates from development was for the team to finish the work in approximately 4 months.  As anyone not directly involved in the project would suspect, the work was far more complicated than that. 

The engine had UI responsibilities, database responsibilities, and middleware responsibilities.  It touched and affected every part of the product – including a significant amount of documentation and example code. The old engine and the new engine wouldn’t connect the same way, wouldn’t have the same interface, wouldn’t run the same code.  There would be changes. Additionally, the old engine had bugs, but the new engine had different bugs. Finally, the developers wanted to take this opportunity to do better – to do more – with the capabilities of the new engine.  Where to start?  How to get the job done?  The lead developer emailed me a 6-page email of questions and concerns.  Yikes. 

I pulled up our market research on the percentage of users who said they used that engine regularly.  The number was high - 70% if not higher.  This was going to be further trouble, as Product Management and Development had believed that only a small number of people actually used the that part of the product. 

We pulled the product experts (Product Management, including the founder and CTO) and the developers into a room to put together a game plan.  First we discussed the usage data and concluded that everyone was right – always a good meeting conclusion :-) – and restated the facts: Most users used some part of the engine, but the majority of them used the functionality for relatively simple purposes. In fact, because we had excellent personas, we immediately recognized that the usage was split across the personas.  That was good news. 

DeskTop had a primary persona and a secondary persona.  For discussion purposes, I’ll call them “Bonnie” and “Clyde” respectively.  We knew Bonnie had far less technical prowess than Clyde and little ability to try a different route to solve their problem. In fact, we suspected Bonnie barely understood what she was doing when she made use of this engine. 

Impressively, with less than 2 hours of discussion, we had a solid, small, set of persona-based guidelines that successfully guided the release priorities, the development and qa (and helped the marketing) of the engine replacement project for the duration of the project, while also addressing the tech lead's concerns. 

The list looked like this:

Rule 1: Both Bonnie and Clyde use the product to reach a satisfactory outcome. (Duh.) 
Rule 2: Since Bonnie would be thrown off her game by new or different outcome – even if that new result was actually a bit better, our development staff had to protect Bonnie by providing the same outcome as before for the functions that Bonnie used.
Rule 3: Since Clyde was thrilled by and skilled to handle complexities in his work and in our product, he would be thrilled with as much nuance, flexibility and capability as we could provide.  Clyde would respect and be excited by better results and wouldn’t be troubled by a result that was essentially the same as before, even if it was presented differently.  Therefore, our development staff was free to expose and make use of the capabilities of the new engine for Clyde’s use and enjoyment, so long as Bonnie was protected as stated above. 
Corollary 1: We fix bugs whenever possible

These guidelines boiled down to the simple statement of “Feel free to wow Clyde but make sure you don’t break Bonnie.” 

And with that, everyone was empowered.  The subject matter expert developers were able to decide for themselves which functionality Bonnie needed to remain unchanged (or they could ask Product Management if they were unsure).  The business and development priorities were clear and the developers were able to decide for themselves if there was time for a Clyde-wowing feature. 

In the end, the project ended up taking 8-10 developers almost 2 years to reach the point of stability.  But until personas were applied to the problem, the project had been unguided and at risk of spiraling out of control.

UPDATE: I re-read what I wrote hear based on Saeed Kahn's question.  To paraphrase, Saeed asked "Isn't this a case of making sure the old functionality worked for the old users and new functionality would be available for the new and powerusers?"  Here's my reply:

Our solution was different from "the old "stuff" has to work as before, or if it is technically not possible, then an automated upgrade path so the old "stuff" is upgraded with minimal user effort and works."  Though this was my starting position as well on the previous release of the product.  Our product, including this engine, had more subtle implications because it included continuous compile, execute and document. We didn't have a datastore that would tell us the previous output, and since we no longer had the previous engine, we couldn't know what they'd used our software to create and couldn't automate an update.  (Clear as mud?)

Anyhow, this product - while still looking to grow - was funded by the existing customer base which was millions strong.  This engine replacement was due to the collapse of a business relationship with the provider of the previous engine.  So we weren't replacing this engine with an eye to new users. (Though we always wanted new users and did other work to gain them.)

In this situation, the old results were very difficult to duplicate and were in many ways sub-standard.  What we needed to understand was:

• The combination of compiler instructions must give an end result precisely as before.  (Knowing that each of these was nearly impossible to achieve, so it needed to be as small a collection and combination as possible.
• The combinations of compiler instructions could work a new way.

It turned out that our persona-based use model captured the situation perfectly.  One persona re-used existing work ad-infinitum (as a sort of robust, qa'd template), so any re-work would affect too many existing projects.  Plus that persona was already over his head with the compiler and asking him to re-implement differently would be disastrous to his work.  Our other persona tended to use our product  The other persona used our product for unique work each time.  He just needed to learn a new way of working.  And that persona tended to be excited by new compiler, execution and documentation opportunities.

We never did and never were able to make a complete list or combination of compiler instructions that needed to work the old way.  We were forced to work on a "I'll know it when I see it" (aka pornography) basis.  Our developers and product managers made good decisions, and then our QA and beta customers second-guessed those decisions until we had done the best we could do.

An additional value of using the personas in this way is they prevented the dev staff from speding all their time on the cool/sexy work they wanted to do, helping them stay focused on the dull/necessary work of the product.

- Bonnie

Re-Writing a Mature Application: How to Succeed

Most people think about new markets and new users, but the fact is that mature products sell to existing customers, plus anyone new.  These existing users (a.k.a. the people who keep your company afloat) have habits, expectations and – most importantly – integrations and legacy data.  These users expect to continue using a new version similarly to the way they used the previous version.  They’ll adjust to UI changes, but they won’t adjust to existing integrations or data being broken.

In addition to great project management and great developers, to successfully re-develop a mature application, I recommend you meet the following terms and conditions:

The application’s features and actions must be well known, well documented, and easily understood by the developers
If the developers don’t know exactly what the feature currently does, how can they redevelop that feature to perform all of the same functions?  ‘Nuff said.

The application must not have undocumented features which are regularly exploited by customers
I’ve worked for companies where the employees believed that by refusing to document an unintended (and often dangerous) product feature, they were refusing to condone its existence and use.  Well, maybe that’s true.  But if you don’t quickly plug up that opening, users will exploit it. Again and again.  Soon, they’re relying on it.  So, if you develop the new product without this critical, undocumented feature, no one will use your new product.

Existing features must not be re-implemented to work differently, unless differently is defined to be a superset of the previous behavior.
The user can learn a new way to do something.  But if he can no longer accomplish something he needs to accomplish, he’ll refuse to use your upgrade.  Better isn’t good enough.  You need to offer everything you offered before and then some.

The Engineers must be eager and able to refer to the original product’s codebase during the implementation process
No matter how good your documentation is, nothing can speak nuance as clearly as the code.  In what order did the rules execute?  What happened when no such conditions were found?  What were the minimum acceptable data elements? These sorts of questions and many others are best answered in the existing implementation.

Don’t end up with customers who refuse your product.  Check out this post from Coding Sanity about “Upgrading” from Vista to Windows XP.

What’s Good for the Gander Might Eventually Be Available to the Goose

A friend of mine recently had his first baby.  He’s a middle manager at a good-sized technology company.  My friend made an arrangement with his management to work 4 day weeks for an extended period of time so he could spend more time at home with his child.  This post isn’t about kudos for my friend who wants to take on bigger than usual burden of childcare, this is about the deal he negotiated at work.  My friend is continuing to receive his full salary for 4 day weeks. 

As is obvious from my use of pronouns, my friend is male.  But even if I had found a way to hide the pronoun, has anyone heard of a woman getting such a sweet deal?

Yes, his boss, (probably sternly) said the familiar, “Make sure you get all your work done!”  But he’s getting paid.  Everyone I know, including me, got the pleasure of getting all of our work done for considerably less pay and often no benefits. Just to be clear, my friend isn’t using vacation time here.  His deal to “work longer days”, though like most people working in technology his day pre-baby were essentially endless already.

Am I upset that a man is getting a deal that women never seem to get?  Yes and no.  No, I’m not upset or jealous about my friend’s arrangement.  I’m very very happy for him.  His excitement about his child is wonderful. And I think the arrangement is a wonderful opportunity for the entire family.  But, I’m very sorry for us women who have to continue to doing more for less. 

On the bright side, my friend’s great deal is surely good news because – just a Sandra Day O’Connor made a practice of fighting for equal rights for men to get those laws and traditions “on the books” – this deal, should eventually lead to equal opportunities for women. At least for women within that company and department.  (Of which my friend said there were “maybe 2”. Sigh.)

Should We Re-Develop Our Entire Application?

Apple'€™s Christmas ads to "Give up on Vista"€ once again got me thinking about whether a company with a mature commercial product has a greater chance of success by:

• Re-developing its entire product

        or

• Re-developing components of the product in a piecemeal fashion

The opportunity to re-build an application under new, modern, technology conditions is seductive.  It'€™s the chance to build the best application everyone can imagine.  The technical staff will make better architectural decisions, eliminating those too-expensive-to-fix bugs and making future enhancements easier.  The UI will be modern and useful.  The code will be clean and supportable.  The product will be better product able to reach further in the market because it can integrate and interact with other programs and technologies built on the newer platforms.  Marketing will love the new product. They can put "€œNew & Improved"€ on all the packaging; they can show off the new interface in pictures.  The entire company will be proud to have a product far better than the competitors'€™ have. 

Meanwhile, modular re-development is limiting.  Developers can'€™t necessarily choose the latest and greatest technologies.  They have to work within the existing architectures and existing limitations of the product.  Most of the current bugs will remain bugs.  Users will be pleased with the improvements but still be frustrated with the overall product.  Marketing will want to know why more couldn'€™t be accomplished.  Everyone in the company will want the technical staff to "€œdo more".

In my experience, wholesale re-development is often a dream that turns into a nightmare as the re-development gets bogged down under the sheer weight of (and the mention inherent in) implementing all of the infrastructure, features, and enhancements of the mature product.  The project gets off schedule and eventually the company is forced to release something that isn'€™t nearly as good as the previous product. 

The reality of modular re-development is accepting incremental updates over time, eventually replacing the entire product so that little of it is brand new and little of it is incredibly old.  (Similar to the maintenance of an aircraft.)  Developers may feel frustrated and disappointed at the start of the project (rather than mid-way through). But, the company's risk is significantly limited.  With a piecemeal approach to re-writes there are fewer dependencies on unknown, un-built parts of the application and fewer moving parts.  The new code will be written.  It will be fine-tuned.  It will be integrated or sometimes grafted into places. (The Bionic Man vs. Frankenstein.)  Even if the worst-case happens and the module gets off schedule and the company forces the release, at least only a part of the application is imperfect rather than the entire product.

Neither of these options seems too encouraging. To be fair, technical development is always a challenge.  That'€™s why we make the big bucks. Good development is about making smart, sometimes daring and sometimes unpopular decisions. Don't let a a re-development effort provide your competitor with the perfect opportunity to steal your market. 

I suspect Apple is feeling pretty good about itself right now.  Certainly all its shareholders are.

The Curse of Knowledge

Does your development team:

• Have similar types of software and hardware expertise?
• Know your product better than most of your customers?
• Wonder why the rest of the company “doesn’t get it”?

If so, your team’s high levels of skill may just get in the way of great innovations.  It’s called “the Curse of Knowledge.”

Check out this article in the New York Times called “Innovative Minds Don’t Think Alike", and then consider about your development team.  According to Dan and Chip Heath, authors of a very enjoyable book called “Make to Stick: Why Some Ideas Survive and Other’s Die”, the curse of knowledge is why engineers design products that only other engineers can use. (Otherwise known as why the remote control has 52 buttons.)

According to the article, Chip Heath says:

You have to bring together people with a variety of skills. If those people can’t communicate clearly with one another, innovation gets bogged down in the abstract language of specialization and expertise. “It’s kind of like the ugly American tourist trying to get across an idea in another country by speaking English slowly and more loudly,” he says. “You’ve got to find the common connections.”

In “Innovation Killer: How What We Know Limits What We Can Imagine – and What Smart Companies Are Doing About It,” Cynthia Barton Rabe describes what she calls “zero gravity thinkers” who are corporate outsiders, smart and skilled but with non-identical skills.  She says they are very useful at keeping creativity and innovation on track by looking at the problem and opportunity from new angles.

“Look for people with renaissance-thinker tendencies, who’ve done work in a related area but not in your specific field,” she says. “Make it possible for someone who doesn’t report directly to that area to come in and say the emperor has no clothes.”

For me, this article highlights the value of the Persona within an organization.  Maybe the Persona is a renaissance idea.  A solid Persona will certainly show whether or not the emperor has clothes and will then provide a clear language for communication.  While you may need a "zero gravity thinker" to help you develop your Persona, it can save you from the curse.

Help Me Create a Persona Workshop

I’m working on creating a Persona Workshop to help Developers, Product Managers, and Marketing folks:

• Learn about Personas
• Develop some sense of how to (and how not to) identify/ create good Personas
• Understand how to (and how not to) communicate and use their Personas to aid communication and understanding throughout their company in support of:

• Product development
• Product marketing
• Sales
• Services
• Roadmap and planning
• New business opportunities

I’d love to hear from all of you about your persona experiences, both good and bad.  I’ll get the conversation going with a couple of horror stories I’ve heard:

Don’t tell your developers the Personas are quantitatively derived.  Personas absolutely must be based on quantitative and qualitative research, but they are still highly subjective.  A good, useful, Persona reflects your company’s values, your competitors, your roadmap and the real reasons your users choose (or will choose) your products.  So, if your developers say, “What’s the P-value of your hypothesis?” you know you’ve overstepped the scientific bounds of your research.

Don’t make a career out of communicating your Personas’ personalities.  Baseball cards with a picture and some Persona facts – Good!  A blog “written” by each of your Personas – Bad!  If you spend hours each day (or even each week) finding new and creative ways to communicate your Persona’s nuances, your Persona is likely highly flawed because it is failing in its purpose to empower others to understand the character, needs and skills of the users and buyers.  (Also, your management is likely to find better use for a head count.)

Don’t name your persona after someone within the company.  (This one actually happened to me.)  We did our persona research and found some great and surprising information.  The personas lead to obvious resolutions to a number of sticky problems and other intractable were suddenly manageable. We just needed to name our personas.  In a mistake I won’t repeat, I sought input from a couple of senior managers.  One manager was extremely helpful and we used the names he provided.  The other manager suggested we use the (rather unique) name of his new Director of Development.  A bit of bias? A desire to seize control?  Just foolishness?  I don’t know, but it was a political hassle that had to be overcome.

A Highly Gratuitous Posting

I’m in the middle of a big project and haven’t had time to write the posting that is on my mind, so I thought I’d post a pretty funny video of me playing with my young daughter.

Then I got to thinking about how this video could be related to building products people love and I realized that YouTube may be the next great resource for discovering and sharing persona related information. Think about it. You can find revealing information about your target user and buyers from their own videos and you can easily compile and share video excerpts.

My video was taken by Joe Shapiro, a member of the Vermeer development team (which went on to become FrontPage) and now a professional film editor and actor (while continuing to work in technology). I don’t recommend this to anyone without children. But if you do watch it, stay until the end because you might be surprised to see who outsmarts whom.

http://www.youtube.com/watch?v=ULQX7Gf7Bv0

Paradigm Shifting Personas

A number of people have written asking how to develop personas for paradigm shifting products that take years to develop.  It sounds like people are falling into a couple of common pitfalls:

Pitfall 1: How can I anticipate the technology of the future and my users’ skills with it?
Pitfall 2: How can my users possibly tell me what their needs when I can’t share with them what I am building?

To answer the first half of Pitfall 1, technology can only be anticipated so much.  We know CPUs will get faster, disk will get cheaper and smaller, and data will be more mine-able.  Other than that, most bets are off.  (Though I personally wouldn’t bet against Windows… .)  So, while your technology may be paradigm shifting, ask yourself this question:

Is your product going to make use of existing technologies and existing platforms, such as the Xbox or Windows, or does it require new technologies and platforms like the iPod (which in addition to paradigm shifting interface includes funky heads that park when dropped)? 

If your answer is that it uses existing technologies, then from a technology standpoint I would recommend you work with safe assumptions (never trusting a company’s planned delivery dates for its new products) and create your UI last, over an existing API, so you will have the most modern interface possible.  If you are driving new hardware or system technologies, then drive them to meet the users’ unspoken goals.  For example, I doubt lots of people said, “hey, I get scared when my laptop fails after I drop it.” since that’s expected and frankly understandable behavior of a laptop, but who among us didn’t cringe and pray when we dropped our laptop? So, the technologists who created that new hard drive recognized it as a feature that would address users’ unspoken desires and concerns.

The rest of Pitfall 1 and Pitfall 2 address how to get the users to tell us their needs. The short answer is that they don’t and won’t.  It’s the rare user who accurately assesses the technology, time, resources and business goals of his/her vendor.  And they rarely accurately gauge their own (or their company’s) willingness to pay for a feature.  If we were to build what they tell us to build, they won’t like it and they probably won’t pay for it.  We’re the experts.  The users need us to listen and observe carefully and empathetically so that we develop a product that meets their fundamental needs and goals. There are no shortcuts.

A SportsWriter’s Case for Personas

In today’s Boston Globe, Bob Ryan makes clear the value of the persona for development and marketing purposes in his article titled A Striking Difference in Outlook. 

Well, actually he’s writtten about the differing points of view, skills and experiences of baseball fans and professional baseball players. According to Bob Ryan, the two groups of people will never understand each other, and he makes a great case based on the odd obsessions and lack of contextual knowledge held by even the most knowledgeable fan versus the years of sacrifice, skills, and the never ending procession of games played by an ordinary (yet extraordinary compared to the fan) major league ballplayer.

What if we re-read this article but replaced fan with user and professional player with professional developer?  I think we’d see a familiar picture.  Doesn’t the user try to tell you, the professional developer, how to get it right?  Doesn’t he criticize the strangest things?  The user doesn’t understand the time pressures, the technological limitations, the poor management decisions, the ever-changing resources and the constant demands for more ....

If the professional ballplayer wanted to understand his fan-base, he would do well to develop a fan persona.  Similarly, if the professional developer wants to understand his user-base, he’ll do well to develop a user/buyer persona.  Having a compassionate, consistent, realistic and relate-able grasp of the people we sell to and build for, but just don’t naturally understand, is an important start toward making a meaningful connection.  Or maybe we should  just hire userwriters, the software equivalent of sportswriters, to help explain to our user-base what we do, why and how good we are?  Oh right, we have that - they're our technical writers.  :-)

Let’s go Red Sox!!

A Good Decision vs. The Right Decision

In model year 1999, Honda Motors introduced the Insight, the first electric and gas powered vehicle in the US Market.  The  Insight is based on the very popular Honda Civic platform.  Over the years, it has won a number of prestigous awards including 3 International Engine of the Year awards, 2 Best Fuel Economy awards, and, in 2006, the redesigned Civic line won the very influential Motor Trend Car of the Year award. The Honda Insight has always has been the most efficient gasoline-powered vehicle available in the US.

The Insight has the features, look and feel of one of the most popular cars in America; it impresses automotive experts and it excels at fuel efficiency – the entire purpose of its differentiation.  Yet, it got rammed in the tailpipe by the Toyota Prius since the Prius' introduction to the market in 2000. 

The Toyota Prius and the Honda Insight sell for about the same price.  They use a different hybrid technology.  (Honda’s is arguably better. It certainly gets better efficiency ratings.)  They’re both family vehicles. They both have very long warranties to reassure the cautious buyer. 

So what accounts for the fact that Toyota sells 5 Prius’ for every Insight sold?  Apparently, it’s that the Honda Insight looks like a Honda Civic while the Toyota Prius looks like nothing else on the road.  When you see a Prius, you know it’s a Prius.

Toyota realized – or lucked into the fact – that the hybrid users/buyers want the world to know that they care about the future of our planet (maybe more than the rest of us) and hope you will consider the joining them in being responsible.

For example, remember Brad Pitt driving up to the Oscar’s in his Prius?  He eagerly talked about the car  with the reporters.  Sure, Brad cares about saving the world.  Does that mean he curtails his airline travel?  Only purchases food made locally?  Makes sure all the materials used on his movie sets are recycled?  I doubt that.  But the Prius gives him the badge of doing good, enables him to encourage others to do good, and actually does some good (so he won’t be mocked later).

To digress slightly, I remember yeeeaaarrrs ago talking to a friend who worked in the creation of paper products.  He told me that recycling equipment was so good that it could produce premium quality recycled white paper that was essentially indistinguishable from the non-recycled white paper.  But it turned out, no one would buy the perfect recycled white because it was too white and they wouldn’t get credit for doing the right thing.  So, to fix their marketing/product problem, someone would dump a box of dirt into the paper goo near the end of the production process so that the final paper product had subtle but obvious dirt specs within it.  Now the paper looked good, and it also looked recycled.

This ego/bragging rights quality of the hybrid buyer seems to have been the critical factor in the Prius’ success and the Insight’s failure.  While the Honda business people and engineers made good decisions when creating the Insight (it's arguably the better car - or based on quality and price should at least have a significant market share), it was the Toyota business people and engineers who had the insight (or the luck) to understand their users/buyers well enough to make "the right" strategic and design decisions such as making the car distinct and recognizable, fuel efficient enough, and price effective.

I write this tome as means of explaining why personas are not just for fine-tuning a design, but may be critical to the high-level decision making and long term vision for a product.

'The Power of The Persona' is here!

Read the hard copy of my 'The Power of the Persona', a case study of persona investigation and application, in your current issue of Pragmatic Marketing's 'Pragmatic Marketer' (not yet available online) or download the pdf from here.

I look forward to your comments!

What Makes a Product Great?

People often talk about the users’ needs, but less frequently discuss the users’ hidden desires or skills. Unfortunately, a product aimed at users’ needs without an understanding of the users’ desires or skills can lead to a product that doesn’t work for its users.

If you think about it, a product's interface is much more than the UI. It's every part the user experiences, including:

• Look and feel
• Performance and speed
• Actions and behaviors
• Content

By focusing only on the features necessary to perform particular functions, products can become too technical or too dumbed down for the users (Microsoft Bob), they might not address some of the users’ less obvious needs (size reportedly killed Apple's Newton), or they may confuse the user with an odd mix of too much and too little feature support.  While Bob and the Newton were Hindenburg-like failures, just think of the last product that frustrated the heck out of you. It simply wasn’t well matched for your needs, desires and skills.

Personas are a relatively inexpensive means of communicating the archetypal user's needs, skills and desires to the development staff. Consider taking the time to develop (or hire someone to develop) really good personas to support your current development efforts and increase your odds of building great and successful products.

Does Persona Drive Product Character?

Here’s an idea I’ve been struggling with since learning about personas: does the right persona drive a product’s character?  I think it does.  In fact, I suspect that most truly addictive products were built, intentionally or not, with a particular user and buyer in mind.

In thinking about this today, I made a quick list of some current, well-known products that have a strong and broad, positive character:

• Nintendo’s Wii
• Apple’s iPod
• Rim’s Blackberry (or crackberry)
• Harmonix Music System’s Guitar Hero
• Intuit’s TurboTax
• UpToDate’s UpToDate

What’s so special about these products, beside their popularity and a strong character? One thing I notice is that most of these products created a user population where there was none.  For example, before the Wii, video games were primarily built for and played by young males. Yet, when I was a little kid (and bread cost $.05 a loaf … ) the whole family enjoyed Pong. Now apparently whole families are rediscovering the pleasures of video gaming via the Wii.  Even the sound of the name “WEEEE” is easy, family fun.  When I think of an ad-hoc persona for the Wii, I imagine Grandpa and John-boy Walton as great personas on which to base the Wii’s development.

Similarly, Apple (aided by some fantastic marketing) transformed the walkman and mp3 player – typically a young person’s entertainment and escape vehicle – into an entertainment and escape vehicle for everyone who enjoys music, young or old.  Once we get music on the iPod, we are transported.  (Yes, I am still bitter about the nights I lost hacking the iPod’s database to load the music.) When I imagine an ad-hoc persona on whom to base the iPod’s character, I think of Loretta Lynn. She’s a smart, older woman with an encyclopedic knowledge of and an encyclopedic collection of country music. She travels long distances and long hours.  She might have arthritis.  She wants to show off pictures of her great grandchildren.  Flipped around, I can almost imaging an iPod having a persona similar to Loretta’s.  It’s great at what it does. It’s good looking and knowledgeable. It’s friendly. It travels well. It performs for long periods of time.  It’s cool. (Hmm, maybe I should have chosen Bono for my iPod ad-hoc persona?)

I don’t have a famous name to pin to TurboTax.  While the product isn’t new, the  merging of the calculation with the documentation of a person’s taxes without relying on black-box calculations and government forms still stuns me in its brilliance.  TurboTax makes so many of us feel more comfortable, more knowledgeable and more in command of our taxes.  When I consider who TurboTax was built for, I think of a blue-collar entrepreneur named “Al”.  Al wants everything nice in life that Wall Street stockbrokers get and he’s carefully earning his way there with his own contracting business.  TurboTax is like Al.  It is in-control, smart, clear. It doesn’t use buzzwords or complex terms.  It doesn’t expect higher eduction, but it doesn’t condescend to people and it is easy and rewarding to do business with.

These obviously aren’t highly thoughtful personas.  But I think they are interesting examples of how a product and a person(a) can relate.

Is Stella a Famous Persona?

I was out with friends recently and found myself recounting a phone call I’d gotten many years ago.  Here’s the text as I recorded it shortly after the call.  I used it as the first scene of my 2nd , unpublished, novel. My friend Amy suggested I rework it as a short, New Yorker-type story and I just may do that.

Stella was sitting on the front porch watching the afternoon traffic pass by when I got the call on my business line.  It was the call I always knew would come.

“Hello.  May I speak with Stella, please?” she said.

“Sure. May I say who’s calling?”

“I’m looking for Stella Woronoff.  W-O-R-O-N-O-F-F,” she said.

“I’m Bonnie Woronoff,” I said. “May I ask who’s calling please?”

“Dunn and Bradstreet has business with Stella,” she said.  I thought her reply a bit haughty. 

“You have business with Stella?  May I ask what kind of business?”

That caused a slight chink in her armor.  “I’m not sure,” she said.  “It doesn’t say here.”

“But you're sure you have business with her?” I said.

“Yes,” she replied, “it says something here about Stella Bear.”

“Stellabear.com,” I said.  “It’s a website.  You have business with Stella regarding stellabear.com?”

“Yes.”

“And you've done business with Stella of stellabear.com in the past?”

“Yes.”

“Well, that's very interesting,” I said.  “I didn't know she was working with Dun and Bradstreet.  Hang on.  I'll get her.” 

I paused a moment, debating…. 

“There is one thing I think you should know,” I said.  “Stella’s a dog.  She’s a big beautiful Newfoundland dog.”

“Oh,” the woman said, though she was dumbstruck only momentarily.  “Is she famous?”

I was impressed by the nimbleness of her response.  Then I realized the woman was entirely serious. 

“Famous?” I said, “What do you mean?  She's pretty popular in the neighborhood, but I wouldn't say famous.”

“Is she famous like Morris-the-Cat or Lassie?”

“No, she’s not famous,” I said.  Then a thought occurred to me.  “Why?  Do you have connections?  I think she should be famous.”

“Uh, no,” the woman replied sounding neverous.  As if I were stalking her. 

“Let me just update her file,” the woman said. 

Damn, I thought. I’d frightened her.

“Is there an option in the file for ‘dog’?” I asked.  As a developer of business systems, I was curious.

The woman then cited my address in Lexington, MA.  “Is that correct?” she asked.

“That’s where I live,” I agreed.  “Stella has a small apartment out back.” I admit it. At that point, I was just messing with her.

“Huh?” the woman said.

“Her doghouse….” 

The woman quickly thanked me for my time.  I thanked her for calling.  When I finished laughing, I joined Stella on the front porch.  She wasn't interested in the story, but she rolled onto her back and let me rub her belly.

Read "the Power of the Persona" in September

Last month in Why a Blog on Personas?, I mentioned a case study I wrote called "The Power of the Persona" to be published in the Pragmatic Marketer, anticipated for August '07.  The current info is that subscribers should be receiving the magazine at the begining of September.

If you are not a current subscriber to the Pragmatic Marketer, you should be. As a Product Manager, I learn something new, thoughtful and/or applicable from each edition. My developer friends seem to appeciate the magazine too. (btw, it's free.)

But, Do Techies Know Their Product Roadmap?

In my previous post, I wrote about my surprise upon learning that the vast majority of my developer and development manager friends believe they have a “clear vision” of who their product actually serves as well as how their product is actually used.  There were two other important questions in my survey, which asked if the respondent had:

1. A solid understanding of their product’s special niche in the market
2. A clear vision of how their product will mature over time.

It turns out that a slight majority of my techie friends believe they know their product’s special niche in the market while only a very small minority believe they have a clear vision of how their product will mature over time.

Ok, I get the product niche result. I agree that most developers know at least a part of their product niche.  Approximately 60% of the techies said they know their product’s niche.  My personal bias – based on 20 years of development experience –  is that they probably know about 60% of their niche.  For example, when I worked at Cisco Systems, I was told that our niche was the fact that our software ran on Cisco routers, the best name in internet infrastructure.  Perhaps that was all there was to know?  But I suspect there was more, or should have been more. 

Still, it’s the responses to the roadmap question that floored me.  I spent some time puzzling it out.  I couldn’t understand why techies would say they don’t have a good vision of how the product matures over time. After all, the techies are the people who see the requirements, give estimates on implementation, make the design decisions and actually do the coding. As the people who implement the product, there are only a few people in a company more powerful at affecting the product than the developers.  How can they not have a vision of how their product will mature?

Of course, being a developer can be incredibly frustrating at times. Feature requirements grow and shrink, and sometimes seem to be made-up. Schedules and priorities change on a daily.  Managers and co-workers (and their opinions, biases and methods) come and go, sometimes with great force. A developer can feel quite powerless in that surf.  However, a truth behind that dynamic is that the developer is more plugged into the priorities of their company and the future of their product than almost anyone else.  The developer may know nothing about the next big sales deal, but if he doesn’t know how his product will mature, who does?

This thought probably leads to some reason for the survey results: Even though developers have a better sense than most of how their product will mature over time, they obviously don’t actually know how it will mature. They know that whatever features they start to implement will change.  They know that even seemingly small requests from the company often have significant implementation ramifications, which then leads to the company making different feature requests.  Furthermore, my survey asked if they had a “clear vision” for the future of the product, not just some vision.  With all the shifting demands that occur during any development project, my techie friends are completely reasonable to say they are unclear about the future direction of their product.

Still, the survey results are surprising.  Why?  Because it’s these same techies who aren’t clear about their product roadmap who are very clear about their product’s users and its actual use. So, either my techie friends spend a lot more time with the users and at customer sites than I did as a programmer and project manager, or they’re overlooking the complexity of real users and real environments. 

Does the shoe fit?

Do Techies Really Know How Their Product Is Used?

Last week, I learned that the vast majority of my techie friends (development managers and developers) believe they know how their product is actually used in the real world and who their product actually serves based on their responses to a short survey.

These results shocked me. 

In my experience, most developers work in fields where our primary value is:

• Our ability to program in the right language,
• Our skills at making good design and architectural decisions, and
• (For long time employees) the deep technical knowledge we have of our product and codebase. 

I have met few programmers who have a deep, credible image of how their product is used or who it actually serves. (Except for the case where the builder is also a user, such as a cellular phone interface programmer at Nokia.)  Even programmers who are subject matter experts in their product’s field often have no more understanding of their product’s users and environment than a professional volleyball player has of my inability to spike a volleyball and what life looks like as a woman not quite 5 feet tall.

To me, image is the key word.  In my experience as a developer, we each imagine a user – or two or three – who help us make decisions when designing and implementing our product.  I believe we ask ourselves, “What does my image need here?”  If the decision requires something we had never considered before, we make our best guess, grow our image accordingly and continue implementing our product.  (Of course, every developer on the project will have a different internal image of the user, leading to those too familiar discussions about what features are necessary and how they should be implemented.)

As far as understanding how our products actually fit into the real world, I have to admit that I rarely gave that a thought when I was a techie.  Sure, I knew my DHCP server had to hand out valid IP addresses, my router balancer had to accurately load balance the demand on the routers, my students had to be able respond to the test questions and be prevented from cheating, my manufacturers able to manufacture …. But I had little idea or interest in how my products fit into the demands and goals of the customers’ everyday life.

So, for all you techies out there: Do you really know how your product is used in the real world? Do you really know who your product serves?  And for your product managers: Do you know these answers?  Do you think your techies do?

I'd love to hear from you on this.  I’m quite curious.

If Personas Are So Great, Why Haven’t I Heard Of Them?

As I talk with more and more people about personas, I find very few who have heard of them. I find this interesting as my social and business spheres are mostly populated with people who build, market or sell software for a living. Of the people I have recently spoken with, some product managers, a few marketing people, and none of the developers (except those I’ve provided personas to) are familiar with the concept of personas. At a recent BPMA meeting, I quickly asked the group how many of them were familiar with personas. Roughly ¼ of the attendees raised their hands. As a persona evangelist I clearly have my work cut out for me.

Here are my top 5 reasons why everyone isn’t yet using personas:

    #5. ‘The Inmates Are Running the Asylum’ was published in 1998, and good news travels slowly.

    #4. Some companies have a respected internal person who advises the developers and marketers on the user and buyer needs, skills and goals.

     This is akin to the ‘feed a fish vs. learn to fish’ metaphor, because while not a substitute for personas, a strong user and buyer advocate will eliminate the screaming need for personas within the development organization.

    #3. You’ve seen cardboard personas and decided personas are just more paperwork.

     IMHO, this is a mistake similar to deciding that OO programming wasn’t useful just because you started working with early version of the MFC.

   #2. The companies using personas realize they have a competitive advantage, and are keeping quiet.

     Not to make you paranoid, but might this include one of your competitors? Have they just put out a great new release? Are they about to?

   #1. Programmers just want to program.

     Personas are the cure for analysis paralysis! If you want to do more programming and less of everything that isn’t programming, tell your management you want a set of rock-solid personas.

While there are probably more reasons than this list of why you may not have heard of or not be using personas, I’m confident it’s just a matter of time before all good developers realize they need a set of personas to go with their requirements.

What Users and Buyers Really Want

The May 28^th issue of the New Yorker included a “Financial Page” article by James Surowieki, called “Feature Presentation” which I found interesting. In the article, Mr. Surowieki describes the “peculiar problem” companies experience when attempting to meet the demands of buyers, who want every possible bell and whistle included in technology products, and the demands of users who want simple, intuitive products that meet their needs. He notes that users have poor skills at evaluating their skills and so purchase products too complicated for their use. Mr. Surowieki contends that since feature creep is the result of giving the user as buyer what he asked for, there is no easy solution.

I counter that there is an easy solution. While I am a tremendous user advocate, I am not a fan of building necessarily what the user explicitly asks for. Rather, I’m a fan of building what the user and the buyer actually want. To build a product people actually want requires us – the designers, the developers and the product managers – to see a much bigger picture than just the product’s feature set. To build a product people actually want requires us to:

• Deeply understand and empathize with the user’s and the buyer’s skills, goals, hidden desires, biases and environment
• Be aware of our product’s roadmap and our company’s plans for the future
• Be cognizant of our product’s special niche in the market

And to use this knowledge in our product planning, product development and product marketing.

Mr. Surowieki writes “In theory, the best strategy is to make complex features simple, packaging all the power and the options people think they want into a design that they’ll find easy to use.” In fact, he and I would agree if I could just rephrase that sentence a bit to “The best strategy is to implement features that are appropriately complex to meet the skills of the user they target, packaging all the power and options people actually want into a design that they’ll find appropriate for their use.”

I think I’ll write to Mr. Surowieki about personas.

Cardboard Personas Aren’t Worth the Paper They’re Written On

Many current development methodologies, including RUP and Agile, recommend the use of personas as a means to help developers represent and empathize with the users’ needs, skills, goals, and desires of the product. This recommendation can appear – I don’t know – overwhelming (?), and may not even be possible for someone within development to accomplish, and so is handled as a bit of process to be overcome. Some casual user information is documented; a work environment is imagined; a silly name is chosen. The resulting persona is likely too broad, too unrealistic and 2-dimensional. This is unfortunate, because a good persona is very valuable, while a carefully selected persona or two are worth their weight in gold.

The reason these methodologies (and I) recommend the use of personas is because they:

1. Focus everyone on the team on the same set of user needs, skills, goals and environment
2. Equally empower everyone on the team to make good decisions
3. Provide everyone with a common language of the user

A good persona should feel like a real person. They have conflicting needs, unspoken career and lifestyle goals, bosses, spouses and co-workers who influence their options and approaches. From a distance, a good persona is someone you would recognize as human, certainly something more than a stereotype. Up close, a good persona is someone the developers empathize with so well that they can consider and evaluate multiple feature implementation options that would satisfy the persona.

All that said, a good persona isn’t good enough to use in development if his/her needs, skills, goals and influences can be superset-ed by a better persona. Remember, one of most valuable contributions of the persona is to reduce the set of concerns from every possible customer demand to meeting this one (imaginary) user’s needs.

It’s as if:

• Before you were looking at the people in grand central station at rush hour, while
• After you are working with one carefully chosen individual from that crowd.

So, one of the important tricks of personas discovery is to carefully choose the one individual whose needs and skills would result in an implementation that meets the needs and skills of the larger group of people. Finding “the right” personas can be difficult, consumes upfront time, and requires a mix of technical, business and product judgment to get right – yet they are well worth the effort.

The good news is that your personas won’t change significantly release to release – at least not any more than a real human beings needs might have changed over that period of time. “The right” personas have immediate and longer-term payoffs including improved decision making in development, empowered developers, vastly reduced rework, lowered frustrations and increased productivity. If you’re still using cardboard personas, you’re shortchanging your development effort.

Microsoft’s “Controversial” Developer Personas

While personas are a very private, internal tool, Microsoft has a nice set of publicly known personas for its programming environments. (Microsoft also has less impressive, far less well-chosen personas for other products.)

Discussed in various places on the web, I have paraphrased the following Microsoft information from its original form on nikhik.net, written by Nikhail Kothari:

We have 3 primary personas in the developer division:

Mort is an opportunistic developer. He creates quick to implement solutions for immediate problems. He focuses on being productive and learns as needed.

Elvis is a pragmatic developer. He creates long lasting solutions within a product domain. Elvis learns about the domain in depth while working on the problem.

Einstein is a paranoid (their word J) developer. He likes to create the most efficient solution to a problem and typically researches the product domain and technology before beginning work on the solution.

While these are 2 sentence descriptions of far more detailed personas, you can probably already imagine how these personas might drive the implementation of a feature.

Nikhail presents the example of implementing security-related controls in Microsoft’s development software. Mort would probably prefer a control that just worked when dropped on the form. Elvis would likely need customization capabilities within the control. He might even want to make significant modifications to its default behavior. Meanwhile Einstein would probably expect the ability to investigate every behavior of the control or might even decide to re-implement its behavior entirely. Given these 3 different viewpoints – or expectations, or needs and desires, or skills and environment – it makes sense that:

• Mort is the primary persona for Visual Basic
• Elvis is the primary persona for Visual C#
• Einstein is the primary persona for .Net

Admittedly, there is a bit of controversy surrounding Mort, Elvis and Einstein. As I read it, some people are offended by the “pigeonholing” of the user. (Those offended are generally users of one or more of these products.) While I don’t agree with the criticism, I acknowledge that personas will always get this rap. Personas aren’t intended to pigeonhole the user. Personas are intended to be very useful implementation guides for the people implementing the product. We must be very careful to never to condescend to the user or their persona. (Remember Microsoft Bob? How about that !@#$ animated paperclip?)

Mort, Elvis an Einstein help the Microsoft developer make good feature implementation decisions in each of their programming environments. As a user of each one of these programming languages at different times and different project needs, I find these personas to be both enlightening and apt as implementation guides, but not as actual descriptions of who I am. I like it when a product works for me!

What Are Personas?

Not familiar with personas? You are hardly alone. In theatre, a persona (Latin for “mask”) referred to a role played by an actor. In real life, we hear the term to mean the social representation people put on display for one another. In product development, a persona is a detailed representation of a fictitious, yet realistic user who helps us understand the needs, skills, and goals of our real users.

The purpose of the persona is to empower the product decision makers – developers, product managers, marketing and executives – to empathize with the user so they naturally make good decisions for the user and thereby produce a consistent, usable product that meets the users’ needs, matches their skills, suits their environment and fulfills their desires.

Personas are particularly useful to development organizations because they:

• Bring a common user, his needs, skills, goals and his environment to the entire development team in a life-like fashion which helps the developers make good judgments while working
• Empower the developers with a carefully chosen user to empathize with, virtually eliminating edge cases
• Unify the product team around a common, natural language of the user, thus improving the quality and tone of design and implementation discussions
• Focus the development team on a single situation, empowering the collaborative environment to naturally build a product that has consistent, predictable behaviors and a strong character

Additionally, personas are very useful to marketing as they inform marketing and sales of the needs and biases related to the buyer. (Remember, the buyer isn’t always the user.)

Personas aren’t a one size fits all concept. Every product or product line will have its own set of personas based on:

• The users
• The market
• The buyers
• The competitors
• The product roadmap

While a product’s set of personas should be quite small, they may include the following:

• Primary personas, or the representation of the primary user of each major interface
• Secondary personas, or the representation of additional users (with different needs, skills and goals) of each primary interface
• Negative personas, or the representation of users who’s needs, skills or goals the interface is explicitly not going to address
• Buyer personas, or the representation of the buyers needs, biases and goals.

While it can be a bit of work to discover “the right” personas for your products, I strongly recommend everyone in product development, product management and marketing have a well chosen set.

Why A Blog On Personas?

Several years ago, I received some fantastic Product Management training from Steve Johnson of Pragmatic Marketing. In addition to Steve’s insightful personal anecdotes about working in and guiding product development and marketing, the training included the advice that “Personas” – or carefully chosen example users – should be used to guide the product requirements, development and marketing.

Something about the concept of personas resonated with me, so I did a good bit of research on personas, including reading “The Inmates are Running the Asylum” a very persuasive book by Alan Cooper in which he first introduces the concept of personas for product development. After several months of research, my sense that personas could be a very valuable tool for influencing the overall goodness of the product under development was stronger than when I’d started.

Let me interrupt this recollection to tell you something about myself. I’ve been in software design and development for 20 years. Over the course of my career, I have sometimes found myself in the frustrating situation of knowing the product I was working on was being mis-built. That is, that the developers and management were making technical and implementation decisions that simply wouldn’t work for the intended user base. Maybe it was my years in technical support, maybe the fact that I am the child of business owners – I don’t know, but somehow, on these occasions I knew that our values and judgments were off. Sometimes I knew better choices. More often I just knew that we didn’t know enough.

This mis-building of product is never intentional, as everyone always wants their product to succeed. Just getting a project approved takes a tremendous amount of work. First, there is the market research, executive presentations, evangelizing, and board meetings. Then there is the research and writing of lengthy requirements, followed by the writing and debating of lengthy specification documents. Until, finally, we get the chance to actually build the product. In the end, it is the developers and their management who really decide what gets built, how and when. Yet, we developers are usually the ones with the least exposure to the user and the market.

Companies try various means to expose us developers to the needs of the user including corporate trips to user sites, user visits to headquarters, highly detailed requirements, lengthy specifications, use-cases, scenarios, etc. However, none of these accomplish what the persona promises to do.

The persona promises us:

• A realistic description of “the right” user and his needs, skills and desires.
• An awareness of the environment in which our product will be used
• The ability to empathize with the user

Thus guiding a team of developers to make good, consistent, long term and common decisions while implementing the product.

I finally got the opportunity to give personas a try. You can read about my experience in detail in the August '07 issue of the Pragmatic Marketer.  Until that’s available, I’ll summarize the experience here by saying: personas brought a sea change at every level. Product decision making improved immediately throughout the organization.

In particular:

• Developers felt empowered.
• Product Management and Development were finally on the same page.
• Product Managers were required to do far less internal evangelizing.
• Developers documented less and coded more.
• First-pass implementations met the users’ needs while matching their skills.
• Marketing improved their customer and prospect communications

It’s now been a few years since I was first introduced to the concept of personas and I remain very impressed with the immediate and long-term impact of good personas.

Since the concept of personas, their value and their impact is not yet widely established, I have started this blog to help get the word out.