Startups, Life and learning

How I Used Customer Development to Snag an Interview with @Dhh

It was on Twitter —the place where all the best discussions start—when I noticed a tweet from Andrew Warner of the infamous Mixergy.com that mentioned he was looking to for someone to join his team.  Instead of asking for resumes and fluffy cover letters, he proposed a challenge. He posted a series of question on his blog and said ‘may the one with the best answers win.” 

The word ‘challenge’ rang in my ears.  Aside from the fact that I was borderline-obsessed with Internet entrepreneurs at the time (this was over two years ago, so of course I’m no longer obsessed with any of them—not even Dave Morin or Chris Sacca) what made me want this job even more was that I. Love. Challenges.

I thrive off of challenges and gravitate towards anything or anyone I feel I’m remotely qualified to challenge.

So I dropped everything that night and took a look at the questionnaire on his blog, hoping that I was one of just a few of his 40k followers that night happened to notice the tweet.  

When I started reading, I began to realize most of the questions were boring (“What do you hope to get out of this opportunity, blah blah.”) which would make it harder to stand out, and frankly, more difficult for me to muster up the motivation to answer the questions.  But just as I was contemplating answering them,  I saw the opportunity buried in the last two questions: 

Which entrepreneur would you invite to do an Interview with Andrew Warner and why?

Get the contact information of this person.

So I was hooked to finding *the* most exclusive entrepreneur to interview and getting his or her information.  

My customer development itch came in mid-google, and I shook my head at what I first started to do, which was google every successful founder to see who had books coming out or sites to promote (as if no one else would think of that).  I thought to myself: no no no.  You must ask the viewers who they want to view.

Why would I, or Andrew for that matter, know who he should interview? The idea is to get eyeballs, engagement, buzz from this interviewer, so why not just ask those eyeballs in advance who they’d be most interested in watching?

So I did.  

I put together one of the most basic methods of customer development, which was never a favorite, but is always the quickest.  It’s called ‘the Survey.’ You write a list of questions and try and get a good number of people to answer them. The more people who answer the questions, the more statistically significant your data will be. 

So I asked one survey question (the shorter the survey, the better) which acted as somewhat of a hypothesis.  I put down  7 names of  people I assumed would be of  interest to others to watch, created a one-question wufoo survey, and that was that. The ask was simple: “Who would you want to see Andrew interview on his next show?” 

David Heinemeier Hansson (DHH), 37 Signals
Mark Zuckerberg (Facebook)
Joel Spolsky, StackOverflow/Fog Creek
Max Levchin (PayPal)
Jason Calacanis (Mahalo)
Mark Suster (Salesforce.com)
Dave McClure (VC, 500 Startups)

Then I tweeted the survey.

Now fast forward a few hours, and this tweet grew some serious wings. It was retweeted and retweeted and favorited and @replied.

"Help me get a job with Andrew from Mixergy.com,’ was ‘the hook’ followed by "Who would you vote for to see interview with Andrew Warner? @davemclure, msuster, @spolsky jasoncalacanis, @Dhh…etc.

Well, it turns out that people really want to help you find a job (even though I already had one at the time). People really want to help you find two jobs if they can.  It also turns out that tagging the contestants turned out to be pretty smart, because my survey question became a contest among the the contestants.  They wanted to know who would win, so they became my affiliates for getting the survey spread out far and wide, and I didn’t have to pay a dime. Brilliant.

Now fast forward two days after the applications were due in, and this is what I get in my inbox:

image

Yup. Those three little words in my inbox.  Just from a little survey; a little cust dev.  

I like telling this story because it’s one of the dumbest, smallest, ad-hoc examples of how far customer development, and art and science of asking your customers a few questions about what they want, can go.

Sure, there are the rare products that have little need for customer development and are all about technology risk (e.g. a cure for cancer), but for the rest of us, validating our hypotheses (getting some facts to inform our guesses) about what our customers want and will pay for is imperative for achieving product-market-fit.

Sure, there were some variables in my story, but in the end, you never know what the result will be, so why not try?  You just might find that the reason for high churn of your family-centric photo-sharing app might not be because it costs too much, but rather because moms are too busy to share photos and find no value in your product what-so-ever.  It’s the harsh realities that will get you the furthest. 

image

If you can read the tiny text from my responses to Andrew’s questions, a whopping 853 people took my survey that night to vote on who they want to see as Andrew’s next guest. And out of that whopping survey pool, David Heinemeier Hansson (DHH), creator of Ruby on Rails and founder at 37signals took 40% of those votes.

DHH’s interview turned out to be one of the most successful and engaging interviews of all time at Mixergy.com, bringing in the most web traffic an interview has ever seen.

Superpedestrian | Positioning and Branding

At risk, I submit a challenge. Let’s first talk about the word “Super-pedestrian”

pe·des·tri·an | pəˈdestrēən
noun
1.a person walking along a road or in a developed area.
synonyms: walker, person on foot; More
antonyms: driver
adjective: pedestrian

2. lacking inspiration or excitement; dull.
"disenchantment with their present, pedestrian lives"
synonyms: dull, boring, tedious, monotonous, uneventful, unremarkable, tiresome, wearisome, uninspired, unimaginative, unexciting, uninteresting, uninvolving;More

(The intent of “Super-Pedestrian” could be misconstrued)

First, we need to *Inspire* by addressing the question “Why do we do what we do?” (People don’t buy what you do, they buy why you do it”) So, what does SP believe? Why does SP do what we do?)

What we do starts with an underlying passion for something- improving the environment, creating technology that makes a difference, solves a daily frustration.

The gap between consumer experience in mobile products like the iPad and the ones we use for sustainable urban living is huge. Why should electronic bikes or other means of transport have to compromise in user experience and design?

"Everyone should have the right to act environmentally sensible, while experiencing the purity, beauty and performance of a Superpedestrian product."

"Everything we do is designed for beauty, ease-of-use, reliability and sustainable urban living."

But what is Superpedestrian if the Copenhagen wheel is a device designed to transform your morning commute by making it more personal, reliable and comfortable?

"Superpedestrian is a ‘think tank’ for sustaining the environment by transforming one’s experience of transport"

Or,

“Superpedestrian” is a vehicle for transportation, communication and Information.”

"We’re Superpedestrian. We transform vehicles of transport.  Everything we do is beautifully designed, easy to use, and intended for sustainable urban living."

"Superpedistrian is “Design for sustainable urban living”

"Powerful, yet pure."

Truth is achieved by those with the courage to reimagine the possible. Those who defy convention and push performance to the limits. Engineer lighter, efficient vehicles. Innovate intelligent technology that anticipates drivers’ needs. And design silhouettes that defy trends and the wind. This is the spirit that drives us. This is Truth in Engineering®.

AudiUSA

Superpedestrian vehicles of tranport—whether they be a detachable motor on stroller that makes exercising with triplets feel like exercising with twins, or be it a transformation of the Segway, (because let’s face it: People are embarrassed to be seen riding them), each Superpedestrian product is beautiful, reliable, and simple-to-use.

For example, for explaining why we reinvented the Segway: “…so we decided to redesign the Segway. One that learns where you live, and where you work. One that makes you feel good when you’re on one”

image

Areas of focus for the brand should always include the following for each product offering:

  • Sustainability: How the product improves the environment
  • Reliability & Safety: Safety with a high IQ: Engineered into every aspect of the wheel are ways to keep the rider safe.  The app tells you when your tire pressure is low, battery needs recharging, or when there are hazardous conditions on the road. Sensors prepare riders well in advance for oncoming traffic, intersections or cars approaching from any direction.
  • Personalization: SP devices transform the experience of transport by providing the rider with personalized, insightful information from the moment you wake up, starting with your alarm clock.  (If SP detects heavy traffic or poor road conditions on your daily route, we’ll be sure to wake you up just a bit early and remind you to bring your umbrella because it’s going to be a wet ride.)
  • Performance:
  • Designed with user experience in mind: Design is our underlying passion. Simplicity and empathy for the end user shouldn’t come at a cost. urbanity shouldn’t come at a cost. 
  • Information and connectivity (not data): Ride smarter. Connectivity (to others, to the environment, to information about what’s happening around you). The information you need, when you need it.
  • Community- Developers, community sharing 
  • Your city (what *you* can do) - political initiatives, etc.

image

Words I’d stay away from, in particular with the Copenhagen Wheel: Smart, Intelligent, Electric, Assist, Eco-friendly, e-bike, electronic, motor,compact

Words I’d emphasize:

Ease, clean design, simplicity, reliability, thoughtful, personal, pushing limits, safety, technology, always on, always connected, peace-of-mind

Last few thoughts:

While I think SuperPedestrian should evoke a more corporate feel to it, I don’t think it should feel very disconnected from it’s product offerings. Each should feel consistent.  

Transportation should be fun and enjoyable and thoughtless. It’s an experience. One that we’re trying to improve, whether our mission is to sustain urban living or to design a better commute to work.  While there are aspects that need to be taken seriously, like how we design for control, safety and reliability, I would position SuperPedestrian (and certainly its products) in a way that’s fresh, light and relatable.

First things First- The Importance of Prioritizing

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." 

StackExchange knows how to build community

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.

  1. 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.
  2. 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.”

And finally,

"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."

A great letter template for acquired startups- you might need this one day

 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:
[ ] Facebook
[ ] Google
[ ] Twitter
[ ] 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!"


(This treasure was found on Git!)

Live what you love

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? Work can wait” or “Listen, you’re young- you have plenty of time to explore new endeavors.”

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 each day? Go for it.  Keep a 9-5 to be home in time for “The Office”? All yours. The funny thing about this country is, you are 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 we you 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?  Seize the opportunity to look back when we’re 80 years old, tired, proud and shocked by what we’ve lived, experience, accomplished.

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.

Why are software development estimates always off by a factor of 2-3?

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)

For Product Managers: Learn to be More Technical

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.

7.  Follow programmers on Twitter and Google+. Read what they read. 

8.  Read Steve Yegge’s Google Platform Rant.

9.  Read Joel on Software,  More Joel on Software and 'Getting Real', the Smarter, Faster Way to Build Web Applications.

10.  Read the 10 Papers every programmer should read (at least twice)

11.  Play around on programmableweb.  Get to know and understand popular APIs and web services.

12.  Stay up to date with Android and iPhone SDKs, and Facebook’s APIs.

Tabs that go Click, Click, Click

Ah, tabs.

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:

Tabs in Safari

And in Chrome you will get this:

Tabs in Chrome

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.

Close button placement on Safari vs Chrome

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:

Closing a tab from the end of the row in Safari

And in Chrome:

Closing a tab from the end of the row 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:

Closing a tab from the end of the row in Chrome

While Safari is not.

Closing a tab from the end of the row in Safari

See how the close-button target moves when closing a couple of tabs in Safari:

Showing where the close target moves when closing two in a row on Safari

There are no such problems in Chrome:

Showing where the close target moves when closing two in a row on 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:

Closing a tab from the left of the row in Safari

Nice work, Safari. Let’s watch Chrome screw this up:

Closing a tab from the left of the row in Chrome

It works!

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:

Resizing tabs in Chrome

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

  1. 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.

  2. 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.

  3. 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:

Google Chrome in Arabic

Space Shuttle Surfer!

Space Shuttle Surfer!

Design is Horseshit!

via yongfook:

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.

Update:

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.

Update #2:

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.

What is your coming soon page for?

“Whenever you find yourself on the side of the majority, it’s time to pause and reflect.” - Mark Twain

via Joel Gascologne-

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

Tagged: #pivot
Loading... No More Posts Load More Posts