I realise it will ruin some of my coffee street cred to say something positive about Starbucks. However, their use of ethnographic research outlined in Maria O’Connell’s Not Just Coffee: Starbucks’ Rise to Success is commendable (and clearly successful):

Starbucks interviewed hundreds of coffee drinkers, seeking what it was that they wanted from a coffee shop. The overwhelming consensus actually had nothing to do with coffee; what consumers sought was a place of relaxation, a place of belonging. They sought an atmosphere.

The round tables in a Starbucks store were strategically created in an effort to protect self-esteem for those coffee-drinkers flying solo. After all, there are no “empty” seats at a round table. Service counters are built out of natural materials like warm woods and stone, rather than plastics and metals, to create a homier atmosphere.

It’s still so frustrating to see how many companies embark on their redesigns or MVPs without doing contextual research first. You might get the usability of your product right, but without utility, it will still be useless. As Milica T. Jovanovic points out in Better safe than sorry:

Startup culture is using a bunch of clichés to tell (mostly) young people that it’s ok to invest an enormous amount of time and energy into something and then let it fail. Well, it’s not ok. It’s bollocks. There is nothing wrong in investing your time and effort into something you are passionate about, but you can make sure that the risk of failure is as small as possible.

In short, do your research first!

Related reading from the Elezea archive: Coffee, sense of place, and designing whole experiences

What do you want people to see when they find you online?

Whether you’re growing a business, starting a blog, or are ready to sell online, you need to make a great impression. Squarespace is the best way to create a modern and professional website, with all the features you need integrated into one platform. Every Squarespace website is mobile-ready, includes e-commerce, and is backed up by award-winning 24/7 customer service.

Try Squarespace today at squarespace.com.

Sponsorship by The Syndicate.

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.

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.

I agree with every glorious word in Erika Hall’s How the ‘Failure’ Culture of Startups Is Killing Innovation. It’s a brilliant and impassioned defense of making design research part of every product development process:

Somewhere along the way, it got to be uncool to reduce one’s risk of failure.

Part of this may be because the risk of failure is dramatically lower than it used to be. But another reason is that many people don’t actually understand what research is, and have somehow conflated concepts like “rapid prototyping,” “lean startup,” “minimal viable product,” and “[insert] other smart-sounding thing to do” with avoiding research.

It’s really hard to not just go ahead and quote the whole article, because it’s so good. I’ll leave you with just one more bit and an enthusiastic recommendation to read the whole thing:

Maybe knocking out a prototype or building a company is the fastest, cheapest way to learn. But often it’s not. Sure, a prototype can tell us if the user understands the potential solution — but if it’s solving a problem no one has, why bother building it in the first place?

Ok, I lied. One more bit:

It becomes immediately apparent, when we try to understand our fellow humans through research, that we are not rational creatures. But when it comes to making business decisions, research helps address that irrationality and increases our chances to succeed. And make no mistake: in a world where design makes or breaks success, all product design decisions are business decisions. Asking the right questions will lead to useful insights.

Bundled Out is a great post by Charles Miller on how every problem Microsoft is experiencing today was written into its DNA in the 1980s. You really should read the whole post, so I’m just going to quote a short teaser:

Software isn’t an industry where the monster company selling the last generation’s product gets to stay being the monster for the next generation. It’s the industry where a thousand hungry small companies are waiting for a shift in the market that will allow them to slay the monster, carve them up and eat them for breakfast.

My thanks to Igloo Software for sponsoring Elezea’s RSS feed this week. Please check them out!

Igloo is now free to use with up to ten people, making it easier to work with your whole team, your customers or your partners.

Your Igloo is built around apps you already know and love: blogs, calendars, file sharing, forums, microblog and wikis.

Start building your Igloo instantly (no credit card required), or check out their awesome Sandwich Videos.

Sponsorship by The Syndicate.

Web hosting is many things to many people. Grandma wants to start a knitting blog? WordPress. New tech start-up needs a server to present their minimum viable product? Ruby on Rails, PHP, and MySQL. HostGator has you covered, and with one-click installs via the proprietary QuickInstall application, free with every hosting plan.

HostGator is with you every step of the way. The Texas-based, award-winning support staff is available via telephone, LiveChat, and email 24/7/365.

From Shared plans, for just a few dollars per month, up to custom Dedicated servers and featuring both Linux and Windows hosting platforms, HostGator has a hosting solution for everyone. Have you ever considered a side business providing hosting services to your own clients? Perhaps you’re a web designer and want to add hosting value for your clients; a HostGator Reseller plan is the answer!

Try HostGator and get 20% off.

Sponsorship by The Syndicate.

Thanks to Tokens for sponsoring Elezea’s RSS feed this week.

Tokens is a Mac app for managing App Store promo codes

Tokens gets promo codes from iTunes Connect, creates shareable URLs for each code and notifies you once they’re redeemed.

The first step to getting your app noticed is inviting bloggers to try it. Promo codes let you give away free copies of your app, but unfortunately they’re laborious to create, awkward to redeem and impossible to track.

With Tokens you create a code with one click and bloggers can redeem it just as easily. By naming the token you can tell who has tried your app and follow up with them. You can also reuse any unredeemed codes before they expire.

Tokens is available now at usetokens.com/syndicate. Elezea readers get a special 20% discount until July using this link.

Sponsorship by The Syndicate.