Everyday we’re faced with decisions. Yesterday, for me it was:
What we should write in the release notes?
What should we name our ios feedback email?
What alert dialog should we display for users who lose internet connectivity after an app crash, that attempt to login with invalid credentials? Should we say ‘retry’ or ‘close’? or Both?!
It’s easy to get distracted with small decisions—and even easier if they seem like ones that will make or break your product. The next time you find yourself or your team sweating every little decision, or debating over a name, color or button for more than five minutes, keep these 3 things in mind:
- You grow into the early decisions you make.
- No decision is permanent.
- No single decision is worth sweating over, because there are thousands more of them ahead of you.
I stumbled across this brilliant metaphor yesterday that Steven Covey (author of 7 Habits of Highly Effective People) uses to illustrates the importance of proper prioritization and time management.
In his book, Covey emphasizes the importance of taking the time to establish a definitive methodology around the things we need or want to accomplish, both in our personal lives and in the workplace. Systematically creating a way of managing all of these ‘things,’ Covey suggests, ensures that we are always focusing on the right priorities at the right time, for the right amount of time.
The metaphor Covey uses to emphasize the importance of prioritization is simple. In short, a guest lecturer was speaking to a group of students when he pulled out a one-gallon, wide-mouthed mason jar, set it on the table in front of him, and began filling it with a dozen, fist-sized rocks.
When the jar was filled to the top, and no more rocks would fit inside it, he asked the class whether the jar was full, to which they unanimously replied, “Yes.”
He then reached under the table and pulled out a bucket of gravel, dumping some of it into the jar and shaking the jar causing pieces of gravel to work themselves down into the spaces between the rocks. He asked the group once more whether the jar was full, to which one suspicious student responded, “probably not.”
Under the table he reached again, this time withdrawing a bucket of sand. He started dumping the sand, which sank into all the spaces left between the rocks and the gravel. Once more he asked the class, “Is the jar full?”
“No!” the classes shouted. “Good,” he said, grabbing a pitcher of water and pouring it until the jar was filled to the brim. He looked up at the class and said, “what is the point of this illustration?” Once eager beaver raised his hand and said, “The point is, no matter how full your schedule is, if you try really hard, you can always fit some more things into it.”
“No,” the speaker replied, “the truth this illustration teaches us, is if you don’t put the big rocks in first, you’ll never get them in at all.”
I recently read a question on Quora that asked, “What are the most effective Power-user Programs?”
The second highet rated answer was (get ready)…
“If you buy a Wendy’s Keychain for $1, you receive a free milkshake each time you go in”
…But that’s neither here nor there. Let’s talk about a real Power-User Program. StackExchange.
Here’s my take.
StackExchange has built a Power-User program unlike any other I’ve seen that benefits both the business and the users. They’ve set a precedent for how user-driven, knowledge-exchange communities should function.
How StackExchange Works:
Power users are identified by the number of reputation points they earn. Points are earned by contributing to the Stack community in positive ways, like adding quality questions and answers, editing poorly written answers, reporting bugs, and welcoming and educating new users.
Points are given to users, by users, and when a user earns enough reputation points he unlocks a ‘vanity’ badge, similar to that of foursquare’s badges.
Power users are granted privileges of varying levels, all assigned by SO Staff, who welcome the Power User with gratitude and open arms. The Power User doesn’t become an official employee, but he gains access to exclusive decision-making.
Power Users’ permission levels resemble that of a site moderator in that he’s able to ‘clean up’ messy posts, migrate questions to more relevant sections of the site, or down-vote inappropriate content. This model works extremely well, because in order to gain these privileges in the first place, a Power User must be nominated by the community as someone trusty-worthy, dedicated, thoughtful and genuinely invested in StackExchange and its mission to organize information.
Still, I think things will only get better. I think Joel and Jeff (in spirit) have a long-term vision that few are aware of. And I don’t think this vision is driven by greed. I see StackExchange as more of a wikipedia than a Mahalo.
Finally, some key differentiating factors between StackExchange and other user-generated, community-driven sites.
- Reputation on Stack is different from Reputation on Foursquare or Get Glue and the like. StackExchange’s reputation score is created using a complex algorithm, allowing it to directly correlates to a user’s intellect, knowledge, skillset, curiosity, interests, communication style, desire to learn and even willingness to help others.
- Stack Profiles (“badges”) will no double become a supplement to a programmer’s resume as gihub is today.
To close, I’ll end with a Spolsky quote he left on hackernews, after he was questioned recently about Stack user’s incentives to answer questions.
“The 60,000 users who write answers on Stack* every month realize that on Stack Overflow, answering questions is about learning.”
“Finally, Stack is more than an information exchange website. It’s the wikipedia for Questions and Answers. To the community, it’s about creating a permanent artifact to make the Internet better. It’s about helping someone solve a problem in five minutes that would have taken them hours to solve on their own.”
Dear soon-to-be-former user,
We've got some fantastic news! Well, it's great news for us anyway. You, on the the other hand, are fucked.
We've just been acquired by:
[ ] Other: _________________
As you are aware, we've always provided a free service, and have never even tried offering a for-pay option. This means we've never had any income and have been operating at a loss for our entire existence.
Since any schoolchild can see this is unsustainable, it should have been more-or-less obvious to you from the get-go that we were either going to crap up the site with ads at a few cents per-click, or that we've always intended to be an acquisition target. You can do the math on that one.
Your personal data which, until just now, was critical to our core business, will be deleted:
[ ] Immediately
[ ] Within a week
[ ] Within 30 days
We are excited to continue our core mission of connecting people with solutions at our new home. Please realize that this is so vague a statement as to be completely meaningless. But we just made so much money that at the moment we genuinely believe this horseshit.
In reality, you will never hear about us or anything we create ever again. We are probably going to end up, like, implementing a new scrollbar for Google Reader or something.
Thanks so much for making our business so valuable and enticing to a much larger company with more money than sense.
Now grab your data while you still can and get out of here,
Shiny happy Shit.ly management ninjas--
Connecting people with solutions
"Shit.ly loves you!"
It’s the first day of Tumblr’s ‘highlight for $1’ feature. I thought I’d try it out with one of my favorite posts about not hating your life.
Chances are If you’re reading this, you’ve experienced this feeling that “yesterday” you were brimming with hope and possibility, and then you wake up the next morning in a room that seems drab, and you got ready for a job that you tolerate, and you’re surrounded by people still wondering what the dot-com boom was. You think, this is not the life you are supposed to be living.
While I’ve been fortunate in many aspects in my career, this feeling became all too familiar.
Then one day, I stopped. I stopped buying the hype, and I stopped running in place long enough to notice that the world doesn’t collapse. Some people will never understand decisions you make that they cannot relate to. Others wish you well. More people than not laugh about what you want to do. Or worse, question the integrity of your decisions. “When are you going to have kids?” or “Listen, you’re young- someday you’re realize this may not be the right path.”
But that one day, I told them what I’d do next. What I want to do, and wont stop until its obtainable. Some of the skeptics in my life aren’t around anymore. That turned out to be a good thing.
By letting go of fear- fear of failure, of rejection, and by letting go of over-thinking and replacing this time with actually doing - you open windows. and then doors. And then you begin to realize that life is in your hands. Yep. You get to choose what you want to do with it.
Want to slum around for the rest of your life? Go for it. Practice law? All yours. The funny thing about the U.S is we’re given the freedom to do whatever you want to do, Whenever you want to do it.
And best of all- you don’t have to do what you hate to live. In fact- you can make a living doing something you love. ‘Make a living’ may have many meanings. It can mean money, or it can mean simply what it states. Living. Because that’s what we all want to do, right? Have the opportunity to look back when we’re 80 years, old proud and shocked by what we’ve lived.
It’s not as hard as it looks. It’s harder. But eventually, if you begin to slowly and habitually learn to visualize and build the ideal version of yourself, you will abandon the comfort of old habits and convenient beliefs. You will face your weaknesses and conquer life’s biggest obstacles in your way.
You will experience doubt, fear, pain and rejection. You’ll learn more about what you have to offer—and what you don’t have to offer. You will nurture your strengths, tackle your weaknesses, accept the things that you cannot change.
Then something magical will happen.
You start living.
What a brilliant piece on Quora by Michael Wolfe. I like a lot of his writings but this essay really struck a chord. So, why is it so hard to estimate software development tasks? Is it a management issue? Is it the developer’s fault? Feature creep? Bad methodology, or lack thereof? Or is it ingrained in the nature of the process?
Let’s take a hike on the coast from San Francisco to Los Angeles to visit our friends in Newport Beach. I’ll whip out my map and draw our route down the coast:
The line is about 400 miles long, we can walk 4 miles per hour for 10 hours per day, so we’ll be there in 10 days. We call our friends and book dinner for next Sunday night, when we will roll in triumphantly at 6 p.m. They can’t wait!
We get up early the next day giddy with the excitement of fresh adventure. We strap on our backpacks, whip out our map, and plan our first day. We look at the map. Uh oh:
Wow, there are a million little twists and turns on this coast. A 40-mile day will barely get us past Half Moon Bay. This trip is at least 500, not 400 miles. We call our friends and push back dinner til Tuesday. It is best to be realistic. They are disappointed, but they are looking forward to seeing us. And 12 days from SF to LA still is not bad.
With that unpleasantness out of the way, we head off. Two hours later, we are barely past the zoo. What gives? We look down the trail:
Man, this is slow going! Sand, water, stairs, creeks, angry sea lions! We are walking at most 2 miles per hour, half as fast as we wanted. We can either start walking 20 hours per day, or we can push our friends out another week. OK, let’s split the difference: we’ll walk 12 hours per day and push our friends out til the following weekend. We call them and delay dinner until the following Sunday. They are a little peeved but say OK, we’ll see you then.
We pitch camp in Moss Beach after a tough 12 hour day. Shit, it takes forever to get these tent up in the wind. We don’t go to bed until midnight. Not a big deal: we’ll iron things out and increase velocity tomorrow.
We oversleep and wake up sore and exhausted at 10 a.m. Fuck! No way we are getting our 12 hours in. We’ll aim for 10, then we can do 14 tomorrow. We grab our stuff and go.
After a slow slog for a couple of hours, I notice my friend limping. Oh shit, blisters. We need to fix this now…we are the kind of team who nips problems in the bud before they slow our velocity. I jog 45 minutes 3 miles inland to Pescadero, grab some band-aids, and race back to patch up my friend. I’m exhausted, and the sun is going down, so we bail for the day. We go to bed after only covering 6 miles for the day. But we do have fresh supplies. We’ll be fine. We’ll make up the difference tomorrow.
We get up the next morning, bandage up our feet and get going. We turn a corner. Shit! What’s this?
Goddamn map doesn’t show this shit!. We have to walk 3 miles inland, around some fenced-off, federally-protected land, get lost twice, then make it back to the coast around noon. Most of the day gone for one mile of progress. OK, we are *not* calling our friends to push back again. We walk until midnight to try to catch up and get back on schedule.
After a fitful night of sleep in the fog, my friend wakes up in the morning with a raging headache and fever. I ask him if he can rally. “What do you think, asshole, I’ve been walking in freezing fog for 3 days without a break!” OK, today is a loss. Let’s hunker down and recover. Tomorrow we’ll ramp up to 14 hours per day since we’ll be rested and trained…it is only a few more days, so we can do it!
We wake up the next morning groggy. I look at our map:
Holy shit! We are starting day 5 of a 10 day trip and haven’t even left the Bay Area! This is ludicrous! Let’s do the work to make an accurate estimate, call our friends, probably get yelled at, but get a realistic target once and for all.
My friend says, well, we’ve gone 40 miles in 4 days, it is at least a 600 mile trip, so that’s 60 days, probably 70 to be safe. I say, “no f—ing way…yes, I’ve never done this walk before, but I *know* it does not take 70 days to walk from San Francisco to Los Angeles. Our friends are going to laugh at us if we call and tell them we won’t see them until Easter!
I continue, “if you can commit to walking 16 hours a day, we can make up the difference! It will be hard, but this is crunch time. Suck it up!” My friend yells back, “I’m not the one who told our friends we’d make it by Sunday in the first place! You’re killing me because you made a mistake!”
A tense silence falls between us. The phone call goes unmade. I’ll call tomorrow once my comrade regains his senses and is willing to commit to something reasonable.
The next morning, we stay in our tents til a rainstorm blows over. We pack our stuff and shuffle off at 10 a.m. nursing sore muscles and new blisters. The previous night’s fight goes unmentioned, although I snap at my idiot friend when he leaves his water bottle behind, and we have to waste 30 minutes going back to get it.
I make a mental note that we are out of toilet paper and need to stock up when we hit the next town. We turn the corner: a raging river is blocking our path. I feel a massive bout of diarrhea coming on…
(by Michael Wolfe)
Hiring managers often debate over how much technological competency is required for product managers to be strong and effective.
Some people want product managers to have an engineering background, while others think this requirement is overrated.
I think it really depends on what an organization needs.
In my opinion, it’s always better to have technical knowledge than not to have it, irrespective of the situation you find yourself in. I personally try to retain as much technical knowledge as possible.
I started my career with a background in English. After a few years as a product manager, I wanted to be more technical.
I was sick of not being able to see eye-to-eye with the engineers I worked with. We lacked a mutual understanding, and I felt like I was in the dark. Everything was fuzzy.
Also, I wanted to grow professionally, and I found this was hard to do with limited technical knowledge.
In my third year as a product manager, I interviewed for a position at Appsavvy. The hiring manager was an ex-Googler who only hired product managers that were former engineers. I told him I wasn’t a former engineer, but I was technical. He asked me was what LAMP stood for. I was nervous and I couldn’t remember the ‘M”. ”Linux, Apache, Memcache, PHP?” I knew next to nothing about software or programming at the time. For all I knew, Memcache and MySQL were the same thing . He said I wasn’t technical enough. I didn’t get an offer. I thought it was unfair to evaluate me with a stupid acronym. It was unfair to consider only my technical knowledge. I had a lot of other skills to offer! Needless to say, my opinion didn’t change the outcome of the interview.
Some people think you need to have a formal education or background in CS to be technologically competent. I think this is short-sighted. It takes time and effort to improve your technical understanding, but it’s possible. I’ve been able to improve my technical skills over the years and have found it to be one of the most important things a product manager can spend his/her time learning.
With a better understanding and appreciation for technology, you will be able to emphasize with Engineers. Engineers will have more respect you and for what you know. Engineers will become more transparent about issues and setbacks, and you become more understanding. You will be able to calculate risks better, evaluate limitations and capabilities, and prioritize features less dependently. You will be taken more seriously by others, and become more confident in your ability to make decisions.
Here are a few tips on how to develop your technical know-how, from lessons I’ve learned a long the way.
1. Don’t try to understand, just listen. I didn’t know how to listen in the beginning of my career. I would try too hard to get a grip on a conversation I didn’t understand. I used to sit (stand, rather) in morning scrum, and It would be hard to hear what developers were saying over Skype. Most of them were in Israel and they spoke too fast and too softly. When I could hear, I was quick to ask questions about everything I didn’t understand. This was a mistake. I was better off sitting back and listening, absorbing what I could. It is a waste of time to try to understand what’s being said right away. Like everything new, it takes time to learn. It’s easier and more effective to listen first, and slowly begin connecting the dots.
2. Google everything. When you hear something you don’t know, look it up on Wikipedia. Even if you don’t understand it right away, you’ll absorb enough information to be able to talk about it, or ask someone about it who is knowledgeable. Usually, you can learn a lot just from getting familiar with a term. Then move on. Don’t try to memorize everything you look up. This is impossible, and would be too overwhelming. Once you hear something enough times, it begins to soak in.
3. Ask what you don’t know on Stackoverflow. No one there judges, and if you ask a really dumb question, hopefully you’re smart enough to use an alias handle.
4. Start a project. After I learned CSS, I finally started to be able to empahsize with developers, which is a really important part of being a product manager. I decided I was sick of using ugly Tumblr themes, and I wanted to make my own. I didn’t decide to learn CSS because I thought I had to, but rather because I wanted to. The reason I recommend starting a project that you will enjoy working on, is because there is a greater chance that you will see it through and not give up. One time I tried to learn Python for the sake of learning Python and being able to say ‘I know Python.’ I didn’t get very far. I still don’t know Python, and I might not ever know it. The point is, learn a skill when you have something motivating you to learn it.
5. Poke around on Github. There are a lot of cool, open-source projects to play around with on Github that don’t require heavy programming skills. At the very least, copy/paste code from projects you find interesting. I find when you’re interacting with code, rather than just looking at it, you get a better understanding of how things work and fit together.
6. Read popular posts on Hacker News every day. It’s an incredibly valuable way to spend time. Posts are thoughtful and well written, easy to read. You will read a long post about someone’s depressive journey using MongoDB and you will be surprisingly stimulated. Also, read the comments. I find they’re just as important to read as the post itself. It gives the article dimension and context.
8. Read Steve Yegge’s Google Platform Rant.
11. Play around on programmableweb. Get to know and understand popular APIs and web services.
Tabs, tabs, tabs. The specialist subject of UI experts everywhere. Should tabs just rearrange horizontally or also detach? How much vertical scroll buffer should a tab have before it detaches? Under what circumstances should it detach? What about reattaching?
This is a short piece concerned only with the different behaviours when closing tabs in Google Chrome, as I think these behaviours are fantastically thought through.
Closing tabs: a masterclass by Google Chrome
There are plenty of reasons why one browser may be superior to another, but I would suggest that tabs play a very big role in a browser’s superiority.
Let’s start by looking at some tabs in Safari (which was once what Chrome is before Chrome was).
If you add a number of tabs over the course of a session you will get something like this:
And in Chrome you will get this:
Closing tabs from the right
The first difference to notice is that Safari puts the ‘close tab’ control on the left of the tab, while Chrome has it on the right.
So what? Let’s close a tab from the end of the row and see what happens. Here’s a before and after in Safari:
And in Chrome:
What’s the difference here? Well, both browsers have resized their tabs to fill the newly-freed window space, but due to the placement of the close button on Chrome, the mouse pointer is immediately in position to close the next tab:
While Safari is not.
See how the close-button target moves when closing a couple of tabs in Safari:
There are no such problems in Chrome:
The Safari user has to hunt for the next close button each time, while the Chrome user can click the mouse button as many times as required in succession, with no movement of the mouse. Aha! It starts to make sense.
Closing tabs from the left
Or does it? This advantage is surely to be reversed when closing tabs from the left of the window? Quite right. Here is how the mouse pointer is required to move in Safari when closing a number of tabs at one time from the left:
Nice work, Safari. Let’s watch Chrome screw this up:
What has happened here? Well, while Safari resizes the width of the remaining tabs to fill the newly available space each time a tab is closed – Chrome does not. So when a tab is closed from the left in Chrome, no resizing takes place, the rest of the tabs move along one, lining up the next close button directly under the mouse pointer, ready for the next click.
Now, Chrome will resize the tabs to fit the remaining space, but only after the mouse has left the functional area at the top of the browser; that is, after the user has finished interacting with the tabs and has moved their attention elsewhere. Here it is, before and after:
When the mouse moves from the toolbar area, the tabs resize.
Closing tabs from the middle of a group of tabs has exactly the same effect as above in Chrome – the tabs do not resize on close, only when the mouse pointer has left the toolbar. Safari immediately resizes the tabs. This means that closing tabs from the middle requires the user to hunt for each close button in Safari, while in Chrome, the buttons are lined up for the next click.
A couple of notes, conclusion
Note that if tabs are closed by use of a keyboard shortcut in Chrome, this ‘delayed resizing’ (i.e. remaining tabs not filling the newly freed space after a tab has been closed) does not happen – the tabs resize immediately, just as they do in Safari. This is, therefore, a very clearly considered assist for those using the mouse.
This resizing trait, although nuanced, is almost invisible to the user. In fact, it wascompletely invisible to me, for weeks, even though I was benefiting from this behaviour every day. It just worked correctly, in all cases – whether closing tabs from the left, right, or middle.
My conclusion is probably this: when a system’s UI is designed in such a way that its behaviours start to disappear – that’s what I call ‘the invisible’.
Endnote: Why is the close button on the right?
Here’s a point: the ‘delayed resizing’ behaviour in Chrome that has been described above means that placing the close button either on the left or right of the tab would have produced the same effect – the ability to close a number of tabs without horizontal movement of the mouse pointer. So why have Google chosen to place the close buttons on the right? I don’t think it’s just to annoy John Gruber.
In this case, I think Google were governed by this thought: by default, an application should exhibit the least-funky behaviour. Although the delayed resizing trick is subtle, natural, and almost completely invisible (as long as the user isn’t actively considering the nature of the tabs themselves), it is still less normal than if the application did not exhibit that behaviour at all.
In placing the close button on the right, Google have assumed that in the majority of cases, users are going to be wanting to close the most recently opened tabs first (likely to be the ones to the far right of the tab group) and have accordingly placed the close button on the right. Why? Because not only does this give the user the ability to close a number of tabs in one go without moving the mouse pointer (which Safari does not), it also means that the app does not need to exhibit the ever-so-slightly less normal behaviour of the ‘delayed resizing’ in the most-common case.
One final point. Tabs open left-to-right because we read left-to-right. If all of the above really was considered by some genial, tab-obsessed Google employee, you would expect a right-to-left language version of the browser to not only open tabs the other way around, but to also put the close button on the left.
Here’s Google Chrome in Arabic:
Here’s a question.
You’re in the iPhone mail app, and you’re looking at your inbox, when a new email arrives. What happens?
Let’s have a look at the inbox. I’m at the top of the list, and the out-of-view emails are shown in faded grey.
If an email arrives now, it pops into the top, and pushes all the other emails down.
Yay, new email!
So far, so obvious.
Next question: what if you have scrolled down the list a little bit, so you’re not at the top of your inbox? What happens when you get a new email now?
Here is your view before you get the email — you have scrolled down to email 4:
In this case, when you get a new email, you are auto-scrolled to the top of the list, where the new email is sitting there waiting for you:
So the behaviour is:
- if you’re at the top of the list, the new email pushes down the existing emails and you stay at the top.
- if you have scrolled down the list a bit, you are returned to the top of the list to see the new mail.
This makes sense until you think about what happens if you have a lot of emails in your inbox. Imagine you have scrolled down a long way to find a certain email, and then, at that moment, a new email arrives.
Being pulled to the top of the list would be annoying in this case. You’d be proudly presented with an email almost-certainly-not-relevant to your reason for being buried halfway down your inbox. You’d have no accurate way of quickly returning to where in the inbox you were, and, over time, you would probably adopt an unconscious worry that this could happen without warning while you were looking for something in your inbox. A worry that you would be pulled to the top of the list because someone, somewhere decided to send you an email. Come on, Apple. Sort it out.
Luckily, they have sorted it out. Good news!
Here’s what happens. If you’ve only scrolled down a little bit and you happen to get a new email, you’ll be returned to the top (which is no big deal, because you knew you were only a little bit below the top, so it’s easy to get back to where you were), but if you are deeper in your inbox, getting a new email does nothing. Have a look.
Here’s the view before the email arrives — we’ve scrolled down further this time, to email 6:
If an email arrives now, nothing happens:
You’re not returned to the top. You get the alert sound and all the other indicators that a new email has arrived, but you stay where you are in the list. Someone has realised, maybe during testing, that it is annoying to be yanked to the top of the list when you’re a long way down, but it is less annoying when you’re near the top.
The magic distance is three messages.
That is, if you are less than three messages down into your inbox, you’ll be returned to the top when you get a new email. Any more than this and you’ll stay where you are. Send yourself an email and try it.
This is serious attention to detail. It’s not something people will show off to each other on the bus, or something that you can put on an advert or trumpet on a feature list. It just makes the app a bit quieter and a bit more well behaved. The addition of this extra detail has made the app less visible than if the detail wasn’t there. Lovely.
I’ve created products / services in the past that have garnered praise for their design. I love good design in all forms - copywriting in particular fascinates me. I’ve never called myself a designer.
Here’s my pitch. This talk of designers as the new kings of startups is becoming increasingly overblown. You are not a beautiful and unique snowflake. Design is merely the barrier to entry to your product not getting lost in the primordial soup of startups. It is simply your ticket to a seat at the table of possible contenders.
Focus on value creation. Design enhances value, it does not create it. Stop creating shitty startups that look amazing. A product or service that is indispensably useful yet looks like ass is infinitely more likely to be successful than a product that solves zero problems but looks like a work of art. Stop this cycle of creating beautiful novelties, getting your 15 minutes, then disappearing. Create value.
I’m going to pull back the curtain. Here’s why so much smoke is blown up designer’s asses in the startup community:
1. Designers tweet and blog
We’re witnessing a simple selection bias. Designers are expressive creatures, they pontificate, tweet and blog about what they do. Ergo, in our little echo chamber of the web we hear more about the importance of design in startups than we do about sales, business dev, ops etc.
2. Design is a cheap way to appear like you’re creating value
It is to a massive degree much, much easier to spend a week pushing pixels to create something beautiful than it is spending a week getting out of your office, finding people who give a shit about what you’re doing and figuring out how to solve their problem to the point where you become so indispensable that if you didn’t exist they wouldn’t be able to fucking live.
3. Everyone’s a fucking designer now
If there’s one thing you can bet everyone having an opinion on, it’s how something should “look & feel” from the colors to the user journey to the text on the screen. It’s the easiest, dumbest scapegoat for your time if you’re an early stage startup still figuring out what the fuck your customers actually want.
My life changed after reading Lean Startup. You should read it too. Whilst nowhere in Eric’s book does he claim Design is Horseshit, the whole point of the book is that above all else, figuring out value creation FAST is the one true rule of playing the startup game. In fact in the book Eric gives multiple examples of startups who in their very early stages were successful at creating value with zero visible product: no fancy website, no shimmering design, they just provided a service over the phone or in-person that people / companies really, reallyneeded and wanted to use.
In the original list at http://designerfund.com/infographic there are successful companies - but these are ones who have solved a real customer problem. Their value is enhanced by their design, it is not caused by it. Chest-beating about design from a startup fund sends a misleading message to early stage startups about where their priorities should lie.
In the past I have been guilty of putting far too much emphasis on polish and design and not enough on value creation. I’m now even embarrassedby some of the things I’ve built, despite them garnering praise for their “design”. They didn’t solve problems! Who fucking cares how it looks!
No more pretty, shitty startups.
I’m not going to use their products, I’m not going to give them my attention, and if I ever catch myself accidentally starting one I’m going to punch myself in the face.
Some final words on this. Some people have interpreted this as me not understanding the value of good design. I assure you I do from experience, tweet at me if you want specifics.
However - create value before exploring how design can enhance the experience. Solve a real customer problem. If you’re an early stage startup with no revenue, don’t even think about design! Think hard about what problem you can solve that a customer will give you $10 for and work your ass off at delivering that $10 of value as fast and as cheaply as possible. It doesn’t even matter if you’re not aiming to make a paid service. If people won’t give you money to solve their problems, it’s not a real fucking problem. It’s just another novelty echo-chamber startup that you might get a chance to flip to a bigger fish if you win the startup lottery. Don’t be an idiot and buy into that. Solve a problem, live forever. The idea that design is what early stage startups should be busying their time with is a notion I find utterly wrong.
Ok here’s the last word. Only because I thought of a clever anecdote.
People are using Apple as a prime example of design being of vital importance to a company. You’ve missed the point. Apple is not a startup, they are a publicly-listed company that provides value to customers in a number of different ways, not just through good design. Your startup is not fucking Apple.
Your startup is like Apple when Apple was a startup. When Apple was a startup they sold computers made of wood and nailed together in a garage. Apple wasn’t concerned with design when it was an early stage startup. Goal #1 was figuring out if people even gave a shit about compact personal computers. So in 1976 they built computers, out of a garage, from wood, and sold them to people.
Don’t compare your scrappy startup to Apple the now publicly-listed company with superstar design team. That’s not how Apple started.
“Whenever you find yourself on the side of the majority, it’s time to pause and reflect.” - Mark Twain
When you’re building a startup, it’s very important to question assumptions. I think one of these assumptions which needs to be questioned is the initial few steps people normally take when they have an idea. One of these steps is the “coming soon” page.
The concept of a “coming soon” page before you have a product is something that has been on my mind for a while now. On first thought, it seems obvious what the purpose of these pages is: surely it is to collect interest from potential users of your product in order to let them know when you’re ready. I think that is probably a good reason for a “coming soon” page, but recently I have been questioning the purpose of “coming soon” pages and how startups can be much more effective with their first landing page.
Why we create “coming soon” pages
With the websites many of us startup founders check out regularly such as TechCrunch always reporting massive growth numbers for startups, it can be easy to assume that the primary aim for a “coming soon” page should be to collect as many emails as possible. It seems logical that when we launch that is the way we are most likely to succeed. I’ve done it myself countless times in the past.
At the same time, there’s a new idea gaining a lot of traction which I think could be sending startup founders down the wrong track. The idea of the “viral launch page” was popularised by Hipster, and the title of the article on TechCrunch makes me cringe: “How A Startup Named Hipster Got 10K Signups In Two Days, Without Revealing What It Does”. These launch pages are now available for any startup thanks to LaunchRock.
What is the goal of a “coming soon” page?
All of the current hype around “viral launch pages” combined with how ingrained the idea of a “coming soon” page seems to be in peoples minds made me question what the purpose of a “coming soon” page is.
I think in many cases, the goal in the mind of a startup founder is to gather as many emails as possible so they can have their big bang launch when the product is finally ready. There is a big flaw with this strategy, and it is that if we take this approach we are assuming that our idea is certain to take off when the product is ready. At the very least, we are putting more focus on the number of emails rather than on whether any of the people whose emails we’ve got will actually use our product. Do we really want to gather hundreds or thousands of emails, like Hipster, without people knowing what our product does? That sounds like a risky strategy to me.
Skip “coming soon”
Quite frequently I hear about other startup founders launching a new idea, and I often hear from them how many emails they’ve collected on their coming soon page. I rarely hear about conversations they’ve had with people. One piece of advice I’m encouraging new startup founders to take on more and more now is to skip the “coming soon” page completely.
By skipping the “coming soon” page, you can really focus on what matters.Instead of a “coming soon” page, put up a landing page for your product. Make it look like the product exists, and then when people try and sign up, show them a page letting them know that you’re not quite ready for them yet. The effort is the same, but this tiny change can give you massive rewards.
Instead, aim for conversations and validated learning
The key benefit of skipping the “coming soon” page is that you can gainvalidated learning about your startup. Validated learning is the measure of progress Eric Ries defines for the lean startup methodology. The concept here is that every change you make should help you learn more about your customers. By skipping the “coming soon” page, you gain validated learning about the emails you collect: they are people who thought your product existed and showed a real interest by trying to sign up. If you have people hitting the page and no one gives you their email, you know there’s a problem with your idea or the way you’re describing it.
Treat your idea as a hypothesis that needs rigorously testing, and treat the emails as people who are happy for you to get in touch with to discuss your product idea further in order to validate that it would solve a real problem for them and that they might actually pay. I don’t think the idea of having a conversation with the people who give you their email comes into the minds of new startup founders enough.
The benefit of this method is also that you can work on your product in parallel with learning about your customers and about how clearly your landing page is getting across the idea of your product. With a few tweaks,you’re very likely to be able to launch the actual product with the same landing page. Your first landing page can be very simple. This is also how I launched my latest startup, Buffer, and it worked pretty well.
Did you have a “coming soon” page for your startup? Do you have one now? Would you do things differently in the future? I’d really love to hear your thoughts on this topic.
Photo credit: Jason Tester