Persona-Driven Development: Meet Customers First, Write Unit Tests Later
“When was the last time you even met a customer?”
(Jeff Atwood wants to know)[http://www.codinghorror.com/blog/archives/001013.html]. Can you picture their face? When was the last time you used their name in a design discussion? Or had them on the phone?
Jeff talks from a post-development, post-launch, post-adoption perspective. Right now the software project I’m brewing up is in the pre-development, pre-launch, pre-adoption stage. So putting engineers on support duty, Jeff’s remedy for not knowing The Customer’s pain, doesn’t quite work (yet).
Paul Graham’s essay “(How to Start a Startup)[http://www.paulgraham.com/start.html]” asserts that creating something customers “actually want” is one of the three fundamental pillars of successful startups. This echoes the first commandment of Business 101, Know thy Customer. On first glance there’s a Catch-22 here, right? You cannot know what your customers actually want if you do not have any customers and you will not have any customers if you don’t have what they actually want.
There are three approaches to jumping out of this strange loop. You can ignore the problem, you can make yourself The Customer, or you can get out from behind your desk and go talk to folks who could be The Customer.
Approach #1: If You Build It, They Will Come.
This has the allure of a Siren’s song, the whispers of Shoeless Joe Jackson in the back of your head. If someone were to ask you to “name a customer that needs your product” would you answer with specific names? If asked “how did their reactions to your ideas, mock-ups, and early prototypes impact what you’re doing” would you have a response? If not, you’re probably ignoring the Knowing The Customer problem.
I’ve fallen for this Lorelei song of ignorant bliss myself, but never again. Three years ago I took a semester leave from college, leased an incubation office, and was off to the races building my killer app. 6 months, 2 part-time employees, a twice-architected and half-implemented J2EE/Hibernate/MySQL ‘enterprise’-grade solution, $7,000 of personal savings, and a broken relationship later I could not concretely personify The Customer. In hindsight, I could not produce a list of names of people who would use my product as soon as it went live. The venture was a spectacular failure and a spectacular learning experience.
Approach #2: Mirror, Mirror on the Wall.
Making yourself The Customer is part of the magical formula behind 37Signals’ Getting Real book, specifically the second short essay in Chapter Two: (What’s Your Problem?)[http://gettingreal.37signals.com/ch02_Whats_Your_Problem.php] Fried's reasoning is simple. If you have an itch, you’re not alone in this world, so you’ve got a market. There are some hidden dangers to this approach, though. As Graham points out, “this is just the kind [of software] that tends to be open source: operating systems, programming languages, editors, and so on. So if you're developing technology for money, you're probably not going to be developing it for people like you.”
Other problems are that it is easy to become lazy and lose focus. When you're the customer and the creator you're more likely to be forgiving of yourself. It is too easy negotiate yourself out of writing the truly useful but challenging stuff ("oh, I don't really need that"). It is easier to get lost in implementation details only you perceive. It is easier to lose focus of what’s big and important and get caught up on the small stuff.
Approach #3: Meet “Likely” Customers, Show ‘em your Stuff, Listen, Rinse, Repeat. This is obvious but underutilized. Why? Sitting down with non-hackers and sharing ideas and paper prototypes is anxiety inducing! What if they don’t like it? What if they don’t get it? What if they think it sucks? Better to find answers now than after you’ve sunk a lot of time into building your “next big thing”. It is easy to put this off because you don’t have enough to show. This is why I’ve gotten into mocking in PowerPoint. It’s quick and cheap. Graham states it pretty plainly, “The only way to make something customers want is to get a prototype in front of them and refine it based on their reactions”.
The big wins of getting out from behind the desk and in-front of The (Potential) Customer are you get to know your product better. By forcing yourself to explain your stuff you get to know your pitch better. Talking about new ideas and new products is one of the most difficult skills to learn. The second big win is you learn who The Customer is and who The Customer is not. You can put a name with a face with a role. You can craft personas that concretely name and characterize The Customer. This shared vocabulary and understanding of The Customers helps teams empathize with and rally around real people.
Persona-Driven Development
From my brief experience in the Developer Division at Microsoft (the folks behind Visual Studio, C#, IronPython, IronRuby, etc.) I couldn’t help but be impressed with how well they know The Customer. Before serious development revs up the program managers do a lot of homework on The Customer. Face-to-face interviews, phone calls, focus groups, surveys, they do it all.
What is the result? Concrete persona profiles. Science-fair like posters hung in the walls which give names to the primary customer personas, talk about their day-to-day lives, exemplify their pains, and show pictures of their faces. It’s hard to lose sight of The Customers you code for when you see their face on your wall every day. It also leads to more effective discussions when the question is “Would Jill use this?” and you know exactly who Jill is and what her problems are, than “Would our ‘customers’ use this?”
If the mantra of test-driven development states it is sacrilegious to write a single line of implementation before writing your unit-tests then the mantra of Persona-Driven Development states it is blasphemous to write a single unit-test before you write The Customer personas that represent real people you’ve talked to who need your product.