In How I Made $4000 Selling A Product I Didn’t Have one entrepreneur explains how his new startup deceived users into thinking the product already existed (even though it didn’t). They did this so that they could collect credit card details to validate whether or not users would actually pay for the product. You should really read the whole post, but here’s a key section:

It doesn’t feel good to deceive prospective customers (or anyone for that matter). I didn’t like this bit. Then again, is there really a big difference between this and in putting up a landing page to test a new idea? I don’t know. I think if your intention is right (i.e. your heart is in the right place), then this deception is more of a white lie.

Is this what it means to be a lean startup these days? It’s at worst fraud, and at best an extremely dark pattern. I get the need for validation before launching a product — I’m a big proponent of it. But the user-centered design and Lean UX methodologies both give us great ways to do validation in an ethical and honest way: through prototype testing with potential target customers.

Prototype testing helps us find out if a product is useful before we launch it — whether it has good utility as well as good usability. Sure, it doesn’t give us absolute validation on whether or not someone will actually pay for it, but that’s unfortunately part of the danger and excitement of creating software. Or are we really at the point where we agree with the ancient Greek tragedian Sophocles when he said, “Profit is sweet, even if it comes from deception”? I hope not.

I just don’t think deception of any kind is ok, even if “your heart is in the right place”. This isn’t user-centered, it’s persuasion. And as Cennydd Bowles put it in The perils of persuasion:

What privileges the designer [or the entrepreneur] to dictate desired behaviour? And since we’re for hire, does that mean we’re ethical relativists, bending people toward whatever agenda lines our pockets?

Profit is sweet, even if it comes from deception.

This isn’t really a post about one entrepreneur’s methods. I’m more interested in where the line is here, and I think this is crossing a very dangerous one. Where does this approach end? At what point will we, as users, constantly have to worry that every time we enter our credit card details online it might be for a product that doesn’t actually exist? Even if it isn’t fraud, that’s not the type of relationship I think we should build with our customers.

Incidentally, I recently watched Mike Monteiro’s excellent talk at Webstock called How Designers Destroyed the World. It’s embedded below — please watch it. But I’ll close with this quote from the talk that I find very relevant to this discussion:

We need to fear the consequences of our work more than we love the cleverness of our ideas.

We’re responsible for the work we put into the world. We always have a choice to be honest or deceitful. And we have to consider how those choices add up in the long term. That’s our job.

I just got back from a week of Product Management/UX training and consulting in Tehran, Iran. I am still trying to process it all, but I consider it one of the highlights of my career. What I experienced in Iran is so different from what I expected that it feels like I’m dealing with some kind of assumption whiplash that I’ll need quite a bit of time to recover from. But I want to write down my thoughts before I forget some of it, so here goes.

I’d like to use this post to discuss both the work that we did, as well as the cultural experience. I think the best way to do that is to take it day by day and go through how my impressions were moulded through each day’s interactions. It’s a long post, but I think this is important. Because if you’re anything like I was before this trip, you have a completely wrong impression of Iran.

How it happened

I was brought over to Tehran by Sarava, the first VC fund focused on investment in technology startups in Iran. Their Founder and CEO, Said Rahmani Khezri, has a vision for the company that I can completely get behind. He finds smart entrepreneurs in Iran, and then he invests heavily in their skills to help them build up their businesses. Said recognized a big need for Product Management and UX training, so Sarava approached Flow to see if we could help.

After months of planning, and almost running out of time trying to get my visa approved, I got on a plane to Tehran on Sept 27th. Our plan was to do 4 days of training, followed by 2 days of usability testing and analysis on two of Sarava’s investments, Beeptunes (online music buying) and Digikala (Iran’s biggest e-commerce site). We also planned the trip around the UX Tehran event, so that I could deliver a talk there.

I knew it was going to be a full week, but I didn’t quite expect how intense it would be. After 6 very long days I was exhausted but exhilarated, and my mind still can’t stop spinning.

Day 1

The training was attended by about 16 people, representing 5 of Sarava’s investments. All the attendees were entrepreneurs heavily involved in their businesses, so it was a big commitment for them to take 4 days out of their work to attend this training (no pressure!).

We spent the first two days on Product Management training, discussing the details of product planning and product execution. I was quite apprehensive going into the first day. I wasn’t sure if the material would connect with people, and I was especially worried about the language barrier. But it went exceptionally well. In fact, we were miles behind after the first day, because we got completely stuck on customer journey maps. The group just didn’t want me to move on until they understood completely.

So we spent a lot of time on the nuts and bolts of customer journey maps, and then I gave them “homework” to go read a bunch of articles about it before coming back the next morning to work on their own journey maps. Here’s one team arguing passionately about their journey map:

Day 1 was my first clue that Iran is not what I expected, and that this was a very special group of people. I immediately saw that Tehran has a small but passionate startup community who are determined to move the web forward in Iran. They challenged me with their questions, and they took to the group work with more enthusiasm than most places I’ve done training. From that first day I felt privileged to be part of this movement.

That night I had dinner with some people my age (30s), and it was amazing to hear their perspectives on living in Iran. Many of the people in our course have lived abroad — London, Canada, US. But they came back because they love Iran and want to contribute to its growth.

Interestingly, none of the women I spoke to about life in Tehran feel oppressed. When men discriminate against them, they don’t take it personally. They just laugh it off as the behaviour of an uneducated, older generation. They are all highly skilled and educated, and they don’t feel any more discriminated against in Iran than they did in their corporate jobs in London or elsewhere in the world.

This generation remains extremely frustrated that the world has such a warped view of Iran, and they are determined to change this view, even if they do it one person at a time. It certainly worked on me, from the moment I stepped off the plane.

Day 2

Day 2 of our training kicked off with more work on customer journeys. I had to adjust my methods and content a bit to adapt to how the group learned. They ask a lot of questions, and take nothing at face value. It’s not that they don’t trust the material. They just want to understand how it works completely so that they can use it on their own products. Here’s a 15s video of one team discussing their journey map:

I also quickly realized that I wasn’t going to get any rest. The group has both an insatiable thirst for knowledge, as well as unlimited stamina to keep working and working and working until they’re satisfied with the result. We went from 8am to 6pm most days, and then they had homework most nights as well. No one complained, ever.

Day 3

Day 3 was another roller coaster ride of a day, starting with an unfortunate Taxi incident where we got lost and I had no idea how to communicate with the driver. I did make a vow never to take another taxi alone in Tehran.

We finished up the Product Management course in the morning, and then started on the UX course. We focused on personas and sketching for much of the day. The picture below shows some of the personas one team created - in Farsi. It’s still amazing to see these techniques applied in a language so completely foreign to my eyes and ears.

Day 4

On Day 4 we finished up the training part of the trip with lots of sketching (design studio with 6-ups to 1-ups to full page wireframes). I was left with an enormous respect for this group as they meticulously applied every step of the process to their businesses. Here’s one group’s journey from 6-ups to final sketch.

One of my many incorrect assumptions about Iran was that everyone obsesses about politics every day. I assumed people here would be fearful, constantly worrying about the government, discussing topics like nuclear weapons and sanctions, etc. Not so. Instead, what I found is normal people living in a normal city with normal problems (traffic!) and normal social life (food!).

One thing is different though. They’re not waiting. For anything. They’re not waiting for a government handout, they’re not waiting for someone to give them a good job with a good salary, they’re not waiting for education to somehow fall out of the air and hit them on the head. No. They work.

The startup culture is amazing, and the entrepreneurial spirit is strong. They find ways to learn, they find ways to build businesses, and they do it not just because they want to make money. They do it because they understand the power of technology to affect people in a positive way — perhaps more than we in the West do. Their drive doesn’t come from wanting to buy more stuff. Their drive comes from something much stronger: a desire to improve their country, and the firm belief that they have the power to do so.

Everyone I spent time with had a deep sense of urgency to them. They want to learn quickly, they want to make great products, they want the world to change their opinion of them. Their enthusiasm is contagious and inspiring.

Day 5

On Day 5 I moved from training to consulting. We started with setting up and running 4 usability tests for Beeptunes. It was so great to see the team take control and run with it. The moderator did great, the note takers did great, everyone played their parts with confidence and skill. The Beeptunes team took it in stride, even though it was hard for them, because users struggle a great deal on their site. But they’re keen to fix things, and happy to see concrete data on usability issues.

From there we drove to UX Tehran, where I spoke to about 300 people about responsive design in emerging markets. There were some challenging questions, as I’ve come to expect.

At the beginning of the week I took these types of questions quite personally, wondering if they think I’m full of it. But I quickly learned that’s not the case. It’s just part of the culture to have strong opinions and be vocal about them. And, from what I hear, complaining about things is practically a national sport in Iran — one they enjoy immensely. From traffic to sanctions to the president, they just love challenging status quo. So I should probably feel flattered that they took me seriously enough to challenge the ideas in my talk. I still have no idea if my answers were satisfactory, but the talk appears to have been well received, at least.

From there we went back to the Beeptunes office to do analysis on the usability testing data. They’re such fast learners that I didn’t have to do much except point them in the right direction. I gave some advice and answered questions about sticking points, but for the most part they went through the analysis exercise with the passion and dedication I’ve now come to expect from Iranians.

Day 6

The last work day started with an amazing breakfast at Cafe Leon. Iranian breads and cheeses, vegetable omelette, a variety of spreads… So good. And a very nice view.

After that, we sped to the office to not only run 5 usability tests on Digikala.com, but also start the analysis process. That was insane and we were all so tired by this point that I’m not sure how much progress we made. But like buddies on a battlefield, we were in it together, and our spirits remained high.

What this trip meant to me

I think above all this trip has given me a renewed drive for the work we do to try to make the web a better place. This has been a difficult year in many ways. I struggled not only with the usual demands of agency life, but also with a frustration when I look around too much and compare myself to others. And even though my passion still lies heavily on the product side, I’ve made peace with the fact that shipping your own product might not be the only way to have an impact in tech. That will probably sound like heresy to some, and I understand that because “just ship” has become such a refrain in our community. It can make those of us who spend most of our time on the product strategy and early design phases feel quite inferior.

I may not have shipped a product last week, but I know that 5 startups in Tehran are going to spend the next few weeks analysing usability test data, and transforming their companies to follow a user-centered design methodology. So I’m going to stop comparing for a second and be ok with that. Because that? That is awesome.

Yet I’m still trying to wrap my head around Iran, and it will probably take a while, because it’s a place of contradictions. The infrastructure is lacking greatly, but there are pockets of extreme modernness, sometimes in the most random places. One night we drove through rough neighbourhoods and dirt streets only to arrive at an amazing Lebanese restaurant. And that’s Tehran. There are derelict buildings everywhere, but you can suddenly turn a corner and see a modern, luxurious villa or movie theater or apartment complex. It’s all very strange.

I’ve heard enough opinions from people in Iran now to know that it is what you make of it. Those who don’t like it will leave. Others will stick around, and work to make things better. There is extreme poverty, the economy is in shambles, the government is not popular, and yet most of the people I’ve met have a positive outlook and firmly believe they have the power to improve the lives of ordinary Iranians. They are fiercely proud of their heritage and will defend it to their last breaths. (I got into lots of trouble criticising the affordances of doors in Tehran… I’m glad that’s the only negative thing I had to say!).

That attitude is a force to be reckoned with, and I enthusiastically align myself with the startup community in Tehran. They taught me a great deal about passion and perseverance, and for that I am grateful. So to my hosts at Sarava and the people of Iran I say: Mersi, Khoda hafez, and I’ll definitely be back.

There are some more photos of the trip on Flickr.

Today I’m going on what is sure to be one of the most interesting trips of my career. I’m going to do a week of UX and Product Management training and consulting for an e-commerce company in Tehran, Iran. It also includes a public event where I’ll be chatting with the broader Tehran UX community about responsive design and product management.

It’s going to be a busy trip with 6 days of solid work, so this is a heads-up that Elezea will probably be very quiet next week. That said, I’ll definitely do a big write-up of the experience once I’m back. I’m really interested to see what life in Tehran is like, and what challenges and opportunities the web community there are dealing with.

Since I feel bad about not writing much over the next week or so, here is a gif of a giraffe that’s not impressed:

See you on the other side!

Ian McAllister states a common rallying cry of the Lean movement in his answer to the Quora question What should a lean startup functional spec / product requirements doc look like?:

Functional specs or product requirements documents invite scope creep and are walking dead documents.

I’d like to start my rebuttal with something Joel Spolsky wrote in Painless Functional Specifications - Part 1, back in 2000:

Failing to write a spec is the single biggest unnecessary risk you take in a software project. It’s as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to “wing it.” Programmers and software engineers who dive into code without writing a spec tend to think they’re cool gunslingers, shooting from the hip. They’re not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for.

Having said that, I’ll admit that the majority of specification documents are bad. Meaning they are long, they are boring, they are done just to check a box to say they were done, they are written once and never updated, and most importantly, they don’t get used during development. That is a situation Product Managers desperately need to avoid. If a spec isn’t being used actively during development, it’s not the developer’s fault, it’s the Product Manager’s fault. It’s up to the Product Manager to understand what kind of document would be useful to developers, and then provide such a document — one that is much, much better than winging it.

The Functional Spec describes how a product works from a user’s perspective. It’s not focused on how it will be implemented (that’s covered in the Technical Spec), but on defining flows and screens, and how users will experience the product. This might sound a bit academic to some, and against the spirit of the Lean movement that’s all about “getting out of the deliverables business”, but we have to remember that documentation isn’t bad. Bad documentation is bad. Good functional specs help teams communicate, save time, and build better products. But to make sure your functional specs fall into the “good documentation” category, there are a few important points to remember:

• Specs should be dynamic. They are not written once and forgotten about. This is why specs shouldn’t be written in Microsoft Word (no more “v27_FINAL4.docx” filenames). Instead, use collaborative tools like a Wiki or Google Docs to make it easier to edit and access the most recent version.
• Specs should be accessible. The spec document isn’t something that the PM writes in isolation before coming down the mountain to hand over their “Ten Commandments” to the development team to implement. Anyone in the organization should be able to access the specs at any time, and team members should be able to ask questions and contribute to the spec. That’s another reason why Word is out, and online collaborative tools are in. Seriously, uninstall Microsoft Word.
• Specs should be flexible. The biggest and most valid criticism of most functional spec documents is that they are too rigid. Most are merely a list of requirements that were written by people far away from actual implementation, and once their job is done, they are unable to adapt in the face of reality. That’s not how it should work. The last 20% (or more) of a spec is always going to happen during development. That’s not only normal, it’s healthy. It means that teams can adapt to the needs of the products and users, and that they are willing to remove, change, or add features if needed (i.e. if the user evidence or business need is there).

The spec isn’t a document that the PM writes the day before development starts. This is a document that is started as soon as a new project kicks off. Create a template in your wiki (or wherever the plan is to store specs), and open it up as soon you start working on a new project. The best way to write a spec is to add information to it as it becomes available. Add the customer journey map as soon as you have it. Add sketches as soon as you move into the prototyping phase. This reinforces that idea that it’s a living document that is open to collaboration, and it also breaks up the workload so that it doesn’t feel like a huge effort to create the spec.

It’s essential to only add relevant content to the spec — nothing more. For some smaller projects it might be ok to skip the customer journey and prototyping phase, and move straight from sketching to graphic design and/or development. That’s ok. Don’t think of the different sections that make up a spec as above the law, think of them as an a la carte menu that you can pick and choose from based on the needs of the project.

Many people roll their eyes at functional specifications, believing it’s part of an old school way of doing Product Management that isn’t relevant any more. But I’ll repeat what I said earlier: specs aren’t bad. Bad specs are bad. If you create documentation that people actually use to build the product and understand why certain decisions were made, how can you argue that it’s not useful? So my advice is, don’t stop writing specs. Just start writing really good ones.

I’m currently working on a Product Management book, to be published by Smashing Magazine early next year. In the book I go into much more detail on the ingredients of a good functional spec. If you’re interested in getting notified when the book comes up, you can sign up here.

Stijn Debrouwere’s Cargo cult analytics is a fantastic talk/essay on how we often get obsessed with meaningless data in the name of evidence-based decision-making. I don’t want to ruin it, because it’s one of those rare must-read pieces, but here’s a small taste:

Pageviews is a vanity metric: something that looks really important but that we can’t act on and that tell us nothing about how well we’re actually doing, financially or otherwise. […]

There’s nothing like a dashboard full of data and graphs and trend lines to make us feel like grown ups. Like people who know what they’re doing. So even though we’re not getting any real use out of it, it’s addictive and we can’t stop doing it.

I’m currently travelling in the U.S., which means I can finally drag some of my favorite apps from the graveyard screen on my iPhone to the home screen. I’m now happily exploring around in Yelp and Fandango, which I haven’t been able to do in a while. Even Foursquare — which I’m already a huge fan of — is suddenly on steroids.

At the same time, there’s one part of Don Norman’s The Paradox of Wearable Technologies that I keep coming back to:

I am fully dependent upon modern technologies because they make me more powerful, not less. By taking away the dreary, unessential parts of life, I can concentrate upon the important, human aspects.

I realize that when apps work well — really well — they do just that. It’s not that they get out of the way in an invisible UI sense. They are extremely visible, and they consume all your attention while you’re using them. But they take away the boring parts of life so you can focus on the exciting bits.

I apologize in advance to those of you who live in the U.S., but please allow me to gush a couple of examples to illustrate my point.

Fandango

Buying movie tickets online is a mission in most cases. Even if you can figure out how to use the site, you’re not guaranteed that the payment gateway is going to work, and there’s often no way to save credit card details for future purchases. But before I came on this trip, I saved some movies I knew I wanted to see in the Fandango app. Once I got here, I just tapped on a movie, the app showed me nearby theatres and times, I bought a ticket using my PayPal account, and I showed my phone at the door to scan the ticket.

All the app does is take the mundane parts out of buying movie tickets — the search for a theatre, the payment, the ticketing process. It lets me focus on what I really want to be doing — watching a movie.

Foursquare

I expected Foursquare to be better in the U.S. than in South Africa, but I’m blown away by its usefulness. Here are some things that really helped along the way:

• Foursquare knows I live in Cape Town and that I check into a lot of coffee places. So when I arrived in San Diego the app told me welcome, and recommended some coffee houses nearby (a friend, who checks into a lot of Mexican restaurants, got that as her recommendations).
• After you check in somewhere, the app tells you where people are likely to go next.
• Because the data set is so huge, I find that the ratings and recommendations work much better across the board.
• For example, the time of day affects the recommendations — breakfast places in the morning, lunch places around noon, etc.

Again, this isn’t earth-shattering stuff. But it takes away just enough of the mundane parts of being in a new city to make your visit that much more enjoyable.

And that’s what good technology does. It’s not necessarily invisible, but it performs a disappearing act on the things you don’t want to do. There are certainly major, wicked problems to solve in the world. But there are also thousands of small, tedious tasks we deal with every day that we can solve with technology.

That’s what’s inspiring to me about these products, and why I’m going to pay much more attention to “small annoyances” as a way to get product ideas.

Your app makes me fat is such a great post about respecting users by Kathy Sierra:

That one new feature you added? That sparkly, Techcrunchable, awesome feature? What did it cost your user? If the result of your work consumes someone’s cognitive resources, they can’t use those resources for other things that truly, deeply matter. This is NOT about consuming their time and attention while they’re using your app. This is about draining their ability for logical thinking, problem-solving, and willpower after the clicking/swiping/gesturing is done. 

It reminds me of Paul Ford’s admonition in 10 Timeframes:

If we are going to ask people, in the form of our products, in the form of the things we make, to spend their heartbeats on us, on our ideas, how can we be sure, far more sure than we are now, that they spend those heartbeats wisely?

We are responsible — at least in part — for how people spend their time. We shouldn’t take that lightly.

John Ciancutti explains how Netflix uses data to make product decisions in How We Determine Product Success:

It can be frustrating to be in a product development environment where force of personality or hierarchy determines product outcomes. At Netflix the focus on customer value makes a teachable moment of those times one guesses wrong. My product intuition is vastly better today for the benefit of my mistakes.

It’s a great read on the importance of listening like you’re wrong when you develop products.

This widely linked post from Benedict Evens definitely deserves all the attention it’s been getting. In Glass, Home and solipsism Benedict talks about the fallacy of thinking that customers care as much about your product as you do1:

You can think of people as users or customers — but they’re not yours. They don’t belong to you, and they may barely even care that you exist.

A little bit earlier he discusses Google Glass and says this:

If everyone you know owns a Tesla and is deeply engrossed in new technology, then the idea that there might be social problems with Glass doesn’t come up — everyone’s too busy saying ‘AWESOME!’

This reminded me of what John T. Gourville calls “The 9x Effect” in Eager Sellers and Stony Buyers: Understanding the Psychology of New-Product Adoption (you have to register for a free HBR account to view the article):

There’s a fundamental problem for companies that want consumers to embrace innovations: While developers are already sold on their products and see them as essential, consumers are reluctant to part with what they have. This conflict results in a mismatch of nine to one between what innovators believe consumers want and what consumers truly desire.

This image from the article explains the concept well:

This might explain why products like Color, Facebook Home, and Google Glass appear destined not to do very well in the general market.

---

1. I’ve written about the same thing before in What users really care about. ↩

In Ford gives up on turning its cars into smartphones Zachary Seward shares a story on how adding seemingly cutting-edge features to everyday products can do more damage than good:

But it seems people have no patience for touchscreens when a simple knob will do. Raj Nair, head of global product development, tells the Wall Street Journal (paywall) that knobs and buttons will return to the dashboards of new Fords for functions like tuning the radio and changing the volume. The company said it would follow the model of its F-150 pickup truck, which currently sports a mix of touchscreen and more traditional controls on its dashboard panel.

This reminds me of a point Aylin Koca makes in her 2009 PhD study called Soft Reliability in New Product Development (PDF link):

Misalignments between product capabilities and user preferences damage the overall success of a product in the market. Especially in the past few years, these misalignments increasingly lead to users rejecting or returning products after purchase. However, technical analyses of such products show that these products fully meet their technical specifications. This is particularly the case with highly innovative products that bear considerable market uncertainty during their development.

Have a look at this graph from Managing product reliability in business processes under pressure that shows the percentage of “No Fault Found” products that are being returned after purchase:

More products than ever are being returned to shops because people think they are broken when they’re not — they’re just really difficult to use. And I guess that’s what Ford discovered as well: easy will beat fancy every time.