Jason Shah

MailChimp Optimizations: Split Testing Subject Lines

Mon, 17 Jun 2013 13:32:00 -0400

I recently received an email from MailChimp announcing an upcoming revamp to their product. It releases today.

Soon after (on the same day - June 11th) I received an email announcing the same thing to a different email address I have also used with MailChimp. But the emails were different.

Professional Urgency: “Important: MailChimp redesign coming soon. Here are the details.”

Flippant Excitement: “New MailChimp is almost here!”

You hopefully optimize your in-app experience, so why not experiment with subject lines, too? Email marketing is essential to many SaaS businesses. Split testing your email marketing is a no-brainer for optimizing engagement and retention.

A lot of people have been doing this for a long time. In fact, MailChimp provides split testing functionality for its customers.

Anyways, I thought I’d share this example with you all and deconstruct their product hypotheses.

//Professional Urgency

Product Hypothesis: “If people know that this is important and if the tone is formal, more people will open the email.”

Professional Urgency takes an approach more natural to enterprise software. It flags itself as needing your attention. This happens often through interfaces like priority inboxes and subject lines that say [Response Required]. But perhaps it’s boring or the subject line tells me enough to know I don’t want to read it, so people won’t want to open it. And so, we test it.

Notice that I didn’t claim that more people would engage with the product. Subject lines may be too far removed from the core product to have an immediate effect on engagement. But open rates are meaningfully correlated with subject lines because the time and action between reading a subject line and opening an email is minimal. The more time that passes, the more actions for a user to take — the more confounding variables that are introduced, the less a user remembers the experience, and less likely for a statistical impact to show up. Put differently, it’s hard to have a downstream effect with fairly cosmetic changes.

//Flippant Excitement

Product Hypothesis: A light, fun subject line will entice people to open the email.

This “Flippant Excitement” approach is quite different from the “Professional Urgency” approach. It banks on a shorter subject line and a fun-loving vibe as opposed to a serious tone.

//Summing Up

I only received these two versions. I’d be interested to know what other experiments they were running. Also, note that MailChimp didn’t test the actual content of the messages in either of these variations. This is also part of the reason why I would measure open rates vs. click through rates. Click through rates are likely to be influenced most by the content of the email itself (vs. the subject line that originally brought me into the email) — in my opinion. So the closest metric is open rate and not CTR. Lastly, this is a fairly small optimization. Ultimately you have to built a good product and have a positive brand association to get people to open and click on lines in your emails.

Don't Underestimate How Much You Can Learn

Sat, 15 Jun 2013 13:50:00 -0400

//Revel in other founders’ mistakes [via Startup Edition]

I underestimated what I could learn by working for someone else, especially because I was arrogant and insecure.

“Yeah, I’m going to be starting another company after graduation. Check me out.” - Hot Shit

When I graduated college, I decided I could do nothing but start yet another company. It was a foregone conclusion. Only a month earlier, I sold my 5-year-old company (for a small sum, mind you). There were so many problems I wanted to solve next. Joining a company would just slow me down. Apparently other people feel this way, too, and jump right in.

I didn’t buy the “Work on 0.0001% of a product that touches millions” argument. The control-freak, narcissist in me wanted to own the damn thing.

Moreover, becoming an analyst for a VC firm or joining some rotational program at Google felt below me at the time. How arrogant. To make matters worse, I already had stated that I never wanted to “work for someone”. So accepting a “normal job” would make me look like a giant hypocrite.

So I decided to fly west to California. The combination of my arrogance about how little I would learn in a real job and my insecurity pushed me to hack on side projects for a year. I let my ego make that decision for me.

Fast forward 2 years. I have been at Yammer for a little while after winding down my recent unsuccessful side projects. The less risky path turned out to be the right one for me at the time.

I have grown perhaps more in my time here than in my time hacking away in solitude.

+ How to prioritize problems and features

When I worked on my own, everything felt urgent. And I’m technical, so I could just build things. This is a gift and a curse. Having to justify *why* something needs to be built to someone else is a powerful force that saves time and improves product.

+ How to measure the right things

When I worked on my own, I didn’t have analytics teams, useful dashboards, and a kickass in-house multivariate testing tool. Sure, you have Google Analytics, Mixpanel, and others. But Yammer has provided a 101 in the AARRR metrics and focusing on engagement, retention, and virality with a certain clarity that I didn’t have on my own. With millions of users, I have been able to measure things on a new level vs. the purely qualitative data I got from user testing with my other products that had much smaller user bases.

+ How to better work with designers and engineers

When I worked on my own, I often have been the designer/engineer/PM. Having a separate UX and UI designer…what a luxury. With these teams of designers and engineers, I have been able to hone my ability to negotiate with the opinionated designer and encourage the timid junior engineer.

Not to mention that my time at Yammer has given me a platform for building a network in tech that I have taken advantage of in full order. When you’re a bootstrapping entrepreneur who hasn’t left his apartment (or shaved) for a week, not many people want to talk to you. Or did, in my case.

When I interviewed at Yammer, I thought A/B testing was seeing how Landing Page 1 did in Week 1, and how, after changing a few things, Landing Page 2 did in Week 2. Amateur.

While my time at Yammer, and now Microsoft, has come with its share of some bureaucracy and blockers to working on things I thought were important, all of the above benefits are worth a relatively cheap, short term cost to me of dealing with a small bit of overhead.

As entrepreneurs, unlike students, we are expected to always have the answers. Investors want projections. Customers want stable roadmaps. Employees want secure jobs. But by believing we already have all the answers, we skip the steps we need to truly find those answers.

Ultimately, there is no one true path to becoming an entrepreneur. There will always be exceptions (and not just extremely rare ones). People who did it another way. People who built extremely successful companies without ever having a “real job”. But it’s foolish to avoid working for someone else just because you think you’ll always know better. You only hurt yourself Working for someone else’s company can be a tremendous experience if you pick the right company, work hard while you’re there, and study your environment. It shouldn’t be overlooked on your path.

For me, the cost of fooling myself into believing I already knew certain things and possessed certain skills was hidden under layers of arrogance and insecurity. But the long term costs could have been huge. I cheated myself out of growth. Don’t underestimate what you can learn.

//Revel in other founders’ mistakes [via Startup Edition]

Your friend's idea is stupid. Now what?

Thu, 13 Jun 2013 16:57:00 -0400

Creating successful products, and companies, is hard: Identify a “good” problem. Build an MVP. Distribute it to enough of the right target audience. Search for product-market fit. Iterate. Maybe get there. Guess at distribution channels. Try those. Correct. Overcorrect. Grow. Maybe get there. Keep the team together. Overcome the hurdles. Maybe get there. Field acquisition offers. Most fall through. Get bought. Everyone complains. Maybe get there.

Odds are that you whomever you’re speaking to will not have the discipline, skill, or luck to pull this off. Maybe you think the idea is dumb. Maybe you don’t think they’re the right person for it.

I have encountered some form of this scenario many times. Usually I just stay pretty quiet, or perhaps act artificially supportive. I don’t love this response. But I struggle to find how to be sensitive to my friend’s feelings, hedge against the company being super successful, and be really honest so as to save them some heartache. So I thought about how I’d like to approach this going forward. How have you dealt with this?

1) Help your friends make their own realizations

It’s probably not helpful for your friend to hear: “That’s a dumb idea.”

I’m not suggesting you just sugarcoat things. But overly blunt statements are rarely useful. Unless, of course, your friend has thick skin and is exceptionally good at channeling inarticulate, blunt statements into something constructive. In this case, that might be taking a hard look inward or raw motivation.

Ask fair, fundamental questions that are helpful.

“How did you get this idea?” “How do you plan on getting users for it? I haven’t seen someone pull this off before - maybe it will be you!” “Do you have other people working on it with you? It sounds exciting.” “What’s your hope for this? It has a lot of potential” “How are you going to support yourself while you pursue this? It’s a big idea and probably requires some capital.”

Questions like these can get people to face hard truths *with* you instead of defending against your inquisition, painting them into even more of a corner. Maybe they will realize that user acquisition will be really hard. Bootstrapping won’t work for them, so they realize they need to fundraise. Asking about your friend’s goal for this product will force them to face their own motivations - be it money, fame, impact, or something else. There’s a difference between being discouraging and being rigorous. Don’t run away from being helpful because you’re worried that your friend is too sensitive.

Provide your friends with constructive resources.

It makes your response less personal, which offloads some of the risk of your friend getting offended. Point them to Quora threads - be it about work / life balance or things that first time entrepreneurs are blind to. Email them articles about other startups, like the one about how Pinterest was actually a four year “overnight success” in the making. At this point, you surely will seem like a downer if your friend is the slightest bit perceptive. Share the exciting view of entrepreneurship as the life of a pirate, while still making them understand that startups are usually not glamorous.

2) Keep an open mind

From Dustin Curtis’ “What a Stupid Idea”

“I want to make an app for browsing catalogs. It’s like a fashion catalog, but you can organize and share outfits,” he said. He pulled out his iPhone and showed me a prototype that barely worked. The UI was decent but clunky; it had side-swiping navigation that only worked every few swipes. He showed me what seemed to be an endless series of women’s dresses. “Nice,” I said. But I had already dismissed the idea. How on Earth would this 20-something guy in Silicon Valley reach his target market of middle aged women? And would they even want such a thing? Did they even own iPhones? I think I asked a series of questions, but I don’t even remember the answers.

“What a stupid idea,” I thought to myself.

As we finished our coffees, I think he sensed my apathy, and we parted ways. But just before I walked away, he asked a question:

“What do you think about the name we’ve been using? It’s called Pinterest.”

Often, very good startup ideas will sound stupid. It’s on you to manage your skepticism. While a healthy dose of it will be useful for your friend, it’s likely you would also scoff if they said they wanted to start a lemonade stand, or an electronics store — businesses which may be less crazy, but perhaps more risky by not being crazy to begin with.

It’s never easy to be honest about the hard truths. But that’s when your friends need you the most. Don’t be a coward. Help them through.

3 Ways to Build Relevance Into Your Product

Thu, 06 Jun 2013 18:22:00 -0400

People expect relevance when using products. If your product is a useless ghost town or a noisy waste of time, people have less motivation to use and evangelize your product. Obviously.

Without relevance in a social product, the news feed would probably be noisy, and you would engage less. Take Pinterest. For them, this would mean you come back to the product less often, you’re less likely to refer Pinterest to your friends and family, and you are less likely to purchase items via Pinterest. Activation, Retention, Revenue, and Referral — 4 of the 5 AARRR engagement metrics Dave McClure promotes — all take a hit. And ultimately, since referrals will be down, Acquisition (the first A and the last metric of the 5) will also weaken. Notice how something like relevance, which is not obviously tied to metrics like acquisition or revenue, has a widespread influence.

According to Chamath Palihapitiya, who built the growth team at Facebook, providing core product value - and not a having narrow focus on virality - is how you build a lasting, high-growth product.

Here are three notable ways I have observed it done by leading consumer tech applications: Pinterest, Facebook, and Google.

1. Curation: People Choose What Interests Them the Most

The benefit of this approach is that there is a high quality signal (voluntary indication of relevant topics). The cost of this approach is that it introduces a burden for the user, and the user may not comply. As a result, more people may drop out of your signup funnel or form a subconscious, negative association that prevents a future return visit. Furthermore, because users may not choose items and forcing them to do so can be a poor user experience, curation cannot be your only tactic.

2. Algorithmically Surfacing Relevance, and The Key: Hiding Irrelevant Content

Facebook has its newsfeed, and much has been written about what goes into EdgeRank: the system that powers relevance and decides which stories appear in your news feed.

It is an obvious product decision to surface relevant content. And algorithms for doing so exist.

But what I am especially fascinated by is how Facebook inflates the perceived relevance of news stories and tucks away less relevant content. Specifically, Facebook tends to only show the names of your friends that Liked stories and hides away people who are not your direct friends, even if you have mutual friends.

Here’s a story in my feed. “David” is a friend. Facebook doesn’t clutter the experience by surfacing other people’s names, and it makes me feel like the conversation is more intimate.

Only when I hover and/or click on the “3 others” do I see who else is involved. Notably, those people are 2 clicks away, whereas my friends “Zak” and “David” are just 1 click away.

On hover

The overlay I get after clicking on “3 others”

This is powerful. After all, there is a cost of new and more. Showing every piece of data and every new thing you can to a user may be tempting, but it is indiscriminate and foolish. Indeed, from “The Tax of New”

Run that line of thinking too many times and you get death by a thousand paper cuts. This is how good, simple products become quite the opposite. Like a Katamari ball gunning for a record score, your product picks up more and more features until one day, your typical user opens up your app to see 4 different toolbars and 50 icons littered across the UI. Or they look through your list of services and have to wade through 32 line items spread across 7 different pages. Or they click to open a menu and are presented with 20 different options. Your app becomes one of the ones that my mom needs to call me to figure out how to use (“Honey, what does ‘release and trust sender’ mean?”).

Expand the Addressed Use Cases: Pulling Content from Other Sources and Diversifying Your Media Types

Sometimes your pages may not be that engaging. And the market may be changing. A once useful product needs to evolve to remain the best way to solve a given problem.

Here’s a view of Google in 2003.

Today, when I search for Tesla, here’s what I get.

Businesses (Places). Images. Maps. News.

Google is ensuring that what I see is relevant to me by covering my user needs fully. The primary tradeoff here is focus and clutter - this page is not as clean as before, but it’s more functional and the design is done in such a way that function and design coexist peacefully.

—

Your product may be new. It may be mature. Either way, relevance is fundamental, so explore ways to keep your users engaged with some of these tactics.

The 800 Pound Gorilla Amazon Tried to Kill is Google's Trojan Horse

Wed, 05 Jun 2013 13:45:00 -0400

OK. So I just got access to Google Shopping Express. Google and Amazon are dancing closer and closer together in the e-commerce / same-day delivery space. But I didn’t think much about Google as a threat even though with Wallet, Shopping, Search, Maps, self-driving cars, and other tech, it’s a natural threat.

[Discuss on Hacker News]

But here’s a dirty secret: Google is offering better products, at lower prices. To be fair, this is just my initial experience, n=1, and I’m not precisely comparing apples to apples. But by partnering with major retailers, Google taps into suppliers that Amazon has neglected (and perhaps tried to kill) for the most part. The 800 pound gorillas in retail. Your Targets of the world. To date, I’d pay 20-50% more for products just to avoid the inconvenience (and corresponding delay) in going to a physical store, like Target.

Now that Google is offering the same convenience (better search, modern user interface, same delivery time) but using local retailers as suppliers, who sometimes offer lower prices, they pose a real competitive threat. And big box retailers might be, surprise, Google’s trojan horse into owning ecommerce.

What do I mean? I needed a shoe rack 2 days ago. So I went on Amazon, picked Prime available items, sorted on price, and picked the prettiest thing that was a low price ($20).

And I ordered it.

Today, when I got access to Google Shopping Express, I wanted to see if I missed out on something. “Did I get a good deal?” is one of the most powerful, and dangerous, questions a consumer can ask.

And, what do you know? I got burned.

A fantastic, wooden, perfectly sized shoe rack for $12 bucks. Almost half of what I paid on Amazon. Based on what I spend on Amazon, saving that much on average would mean saving something like $2000-$5000 a year.

Now, Google has to make sure its free delivery thing becomes well adopted the way Amazon Prime was, because the $4.99 delivery was a non-starter for me, and ruined the gangbuster economics. But Google still would be cheaper even with the shipping cost.

Apples to Apples (for this *ONE* product)

Google: $13.24

Amazon: $16.17

Caveats: This was only off of ONE product search. Yes, the products that I originally thought to buy weren’t exactly the same (but in the above apples to apples comparison, they are, and Google wins). My taste is subjective - not everyone agrees I got a better deal. I’m not sure if Google will offer Shopping Express at the same or better price, with the same or better service, as Amazon Prime. I love Amazon, so I promise I’m not being a hater.

But, all I know, is next time I search for something to buy on Amazon Prime, I’m going to check Google Shopping, too. And if Amazon loses the monopoly it has on my online shopping, that’s very dangerous. If this experience becomes like flight search for most people who check multiple online aggregators vs. a loyal Amazon Prime base that just goes to them and orders whatever works, that too, is very dangerous for their business. Too bad Amazon can’t just acquire Google Shopping Express. Google did acquire a bunch of startups that probably enable what you see today in Google Shopping Express. This makes me better understand why big companies compete for such hot startups sometimes, especially if they know a competitor is building a strategy that can eat their lunch.

I just wrote this on a whim after being annoyed a better shoe rack cost less on Google than on Amazon. I might be terribly wrong about this. So, tell me why I’m wrong in the comments. I’m really curious to see how this market evolves.

http://www.adexchanger.com/ecommerce-2/google-buys-its-shopping-partner-channel-intelligence-2/

What Yammer Uses. What HeatData Uses: Tools to Get It Done

Thu, 30 May 2013 23:53:00 -0400

(This essay is part of a collaborative blogging experiment to answer the question, ‘What Tools Do You Use at Your Startup?’)

To answer this question, I considered listing off tools I use at HeatData and Yammer. But that felt unsatisfying.

It began to feel like it would become another review of Google Analytics, KISSMetrics, MixPanel, Flurry, Crashlytics, Marketo, SendGrid, Amazon Web Services, and so on. I didn’t want to add to the pile.

From Zach Holman’s “How GitHub Uses GitHub to Build GitHub”

Instead, I’m reframing the question as: “What are the biggest challenges your startup faces, and which tools help you overcome them?” And for fun, I’ll do it for both Yammer and for HeatData. One, an acquired startup now part of Microsoft. The second, a TechCrunch Disrupt hack that is evolving into a company on the side.

Yammer

At Yammer, we have 7 million users and growing. We have more than 100 engineers, a mature product team with actual user researchers, separate UX and UI designers (!), and a stellar analytics team of economists and PhDs. We have enterprise customers we can’t screw with. Here are some of the challenges we face and the tools to address them:

+ Increase retention and engagement of users

This happens by improving the product experience. That is driven by releasing new features that quantitatively increase metrics like “days engaged”, “7 day retention”, “posting binary” (more people posting), etc. And removing features that either hurt metrics or are distracting from useful features. So what tools do we use for this?

Google Docs to write specs. GitHub, Jira, and an array of other tools for development. Vertica for data warehousing and an in-house A/B testing tool.

+ Work well with designers and engineers

We use Dropbox (and Yammer) to share files. We use Yammer (of course) to chat about design and implementation. Unfortunately, no tool suddenly ensures that PMs, designers, and engineers work well together. Good thing we’re all friends.

HeatData

At HeatData, it’s more or less just me, not counting contractors and advisors. I have a handful of customers. I want more. I have a sellable but ever-incomplete product. Here are my key challenges and what I do to get the job done.

+ Iterate on the product

Track usage through Google Analytics. I abandoned Mixpanel because I didn’t want to set up a whole slew of events that got mixed into the actual code of the product.

Use Trello to manage a priority list of bugs and features.

TextWrangler and Cyberduck to write and push code.

Olark to collect customer feedback.

+ Increase sales; deliver amazing customer support

Streak is a beautiful, easy to use CRM tool right inside of Gmail. Highly recommended for early stage startups. Yesware to see if people open my emails ;) (and maybe do a creepy followup right after)

WebEx to do sales calls. And sometimes the phone or Skype.

…

That’s it. I left plenty of tools out. Sorry.

But these are the ones that are helping me with my biggest challenges.

Which do you use? Which should I abandon for something way more awesome?

—

They Don't Take Chances. You Set Yourself Up.

Sun, 26 May 2013 14:57:00 -0400

(This essay is part of a collaborative blogging experiment to answer the question, ‘Who took a chance on you?’)

When I read Bijan Sabet’s “Who took a chance on you?” post, I enjoyed it but felt unsatisfied. The post is a sincere thank you to people in his life who gave him an opportunity despite reasonable risks: to be a good husband, to be a good investment partner, and to be a good investor and board member. As time would tell, things turned out well in each of the cases he shares even though the people on the other side of the table could have rationally walked away from Bijan.

I don’t know Bijan, but I felt unsatisfied because my guess is that he earned it in each of those cases. He was probably a good boyfriend, a promising investment partner, and a compelling investor when people made rational choices to “take a chance on him.”

Some people took chances on me, too

If I were to follow his model, I would be thankful to some mix of my family, some teachers, Yammer, and individuals in both my personal and professional lives. To be clear, each of them took some risk in supporting and investing in me. But not in a mundanely grateful way for people doing all of the cliche right things that Hallmark reminds us about.

“Sure, son, go start an education company.”

Indeed, my parents took a chance on me. No, not by simply having me as their son. But when they, despite plenty of financial obligations, invested $10,000 in my first company when I was just a green high school student touting a 60-page business plan. I clearly didn’t know anything about lean startups and customer development.

“Sweetheart, we have only been together for a semester, but let’s keep this going with you in Boston and me in North Carolina…for a couple years.”

My girlfriend of nearly five years originally took a chance on me. We began dating when she was a college senior, and I was sophomore — an unusual older girl / younger guy set up, especially in college, not to mention how loud and obnoxious I was when we first met. We took a chance on each other, deciding to stay together when she graduated just five months later, knowing we would have two years of long distance ahead of us. A risk for both of us.

“So, you’ve started a couple companies and recently failed fantastically? Yeah, come build shit with us.”

Professionally, Yammer took a chance on me. I had no formal product management experience. During my interview, I believed that A/B testing was putting up one homepage during Week 1 and seeing how a different homepage performed during Week 2. Yikes.

Did they really take a chance?

But none of these moments inspire me. I don’t really feel like a chance was taken. My parents loved me, and I had a good idea that could be monetized. My girlfriend and I were equally scared to lose each other, so the bigger “chance” was breaking up. And Yammer was nearly 300 people / thought I could do a good job, so I was not really a risky hire.

So what’s the point? I am not exceptional. Lucky? Sure. And maybe I just have not had that turning point in my life when someone else bets the house on me. In fact, it’s just as often that people have *not* taken a chance on me — when my little league coach pitched his own son over myself and other good pitchers in the state tournament (and we lost), when it was hard to make friends after moving to Florida in 10th grade, and when it was damn hard to find a customer or strategic partner for my second startup.

People don’t take chances. You set yourself up for people to bet on you.

The point here, I believe, is that we get to where we end up going by setting ourselves up. I made friends after moving only once people saw me doing interesting stuff at school. I got my first company off the ground after receiving media attention, and people believed there was something there since the media did first. Most people are risk-adverse, so we can’t bank on people taking a chance on us if we want to craft our lives for ourselves instead of just living a life that happens to us. Instead, we have to make incremental improvements to who we are, so that people who have to make decisions about us - to be with us, to work with us, to invest in us - are justified in backing us. After all, irrationality is not something to expect or bank on. And incremental improvements fortunately don’t come fraught with risk, but they mitigate it.

Decision-makers may still end up being wrong; it’s not taking a chance unless there is a real possibility of failure. But it’s our job, people who want to craft meaningful, deliberate lives, to make it so no one even feels like they are taking a chance on us. Luck still matters. But there are always small improvements we can make to ourselves that bring us closer to being the person people feel comfortable supporting so that it never really even feels like taking a chance.

Technical Chops for Non Technical Product Managers

Sat, 18 May 2013 13:57:00 -0400

Product People Need Tech Chops

Product Managers should understand the technology that drives the products we build. After all, an effective product manager has a bold product vision, has the trust of engineers, and makes smart tradeoffs. Each of these is strengthened by understanding the power and limitations of the technologies used to build a product.

Ultimately, I do believe that knowing how to program is the most effective way to understand technical implementation. So these conceptual descriptions are certainly incomplete and imperfect. But they are aimed at simply priming PMs who need the basics to get started.

So here are some concepts (and PM questions!) to get going if you either don’t know how to code or know how to code but need to know which pieces are essential for product management.

Frontend (client-side) / backend (server-side)

Frontend is the look and feel. The languages used: HTML/CSS/Javascript mainly. Backend provides data from a server. The languages used: PHP/Ruby/Python.

Doing more on the client-side tends to be bad because it hurts “performance”, which we will cover next. More on the server (calling a million rows from a database) also isn’t good, but server processing tends to be faster than client-side processing. Why? Generally speaking - web browsers can only be optimized so much. Intense servers that are optimized for data receiving / sending (reading / writing) can process much faster.

PM Question: We need to test what happens when we make our feed more legible. What sort of engineers do we need?

Well, chances are that legibility has to do with font size, line spacing, color schemes, and more frontend changes. This can be done through HTML and CSS. That is front end. The content that is being served up is being handled on the backend. So you may need “one frontend engineer” to implement changes to test a legibility change. But I said “test” - so what if you want to run this as an A/B test? You may need a backend engineer who can manage the treatment sent back to the user from the server and sending data back to a server around how this feature affected the user base. Wikipedia has more on frontend and backend differences.

Performance

Is your application slow? That’s poor performance in a very simple sense. Product managers need to understand performance because it impacts what sort of features you envision, how you consider tradeoffs, and whether you build good products.

For example, imagine you wanted to test a mentioning feature in your product, so your users can reference other users in posts. Typically this updates as the user types. Therefore, it happens “client-side” and needs to perform quickly. Otherwise, there will be a lag and poor performance tends to correlate with reduced engagement and lower conversions.

PM Question: What algorithm would you use behind an initial test of a mentioning feature?

My Answer: Alphabetical. The trap here is to suggest some complex relevance algorithm that may, just maybe, work really well. Even better than either a random sort or an alphabetical sort. But the goal here is not perfection. So there’s 2 concepts to keep in mind: MVP and performance.

MVP. Minimum viable product is the smallest, representative version of the feature you’re aiming to build (in this case). Creating a complex algorithm is not small. Alphabetical sorting is, especially because this is a long-standing, built-in technical function. For MVP, iterative development and building smaller things is better, so you can course-correct more easily.

Performance. Without being technical, one may believe all algorithms are created equal. That computers “just do it.” But when it comes to performance, think of computers more like humans. They have to *do* things. Get the members, fetch the relevance inputs that the crazy PM devised, calculate relevance for each member, render that sort back to the client, etc. Your mentioning feature will be very slow compared to “Fetch the members and sort them A-Z.” Imagine if someone asked you to put your pants and shirts in two different piles. Then what if they asked you to also sort each of those individual piles by color, size, and material. You probably would be much slower with that second task than the first task. This is be the difference between a snappy, 0.2 milliseconds load, vs. a 2,000 millisecond (2 second) load.

Databases and Tables

A database is simply a place where information lives. You store tables in a database and the tables contain rows and columns of information you define. Imagine a Google Doc with rows and columns for you to read from and write information to. That’s a table. Usernames and hashed passwords. Locations of media files corresponding to profile pictures. Raw information that you need to serve back to users. These pieces of information live in tables.

The database (and its tables) lives on a server somewhere, so it will not be “client-side”. Imagine having to access millions of rows of information - you couldn’t possibly load that whole thing into the webpage every time you needed to just look up one tiny bit of info. But you could fetch the single piece of info from the table through a SQL query or something like that and then that one small, relevant piece is delivered to the client. It would also be a security risk to send back data that should not be accessible to the user trying to access your site (e.g. other users’ data).

Clients

“Clients” refers to the channels through which the application is accessed (the website or mobile app is used). So, there’s the web client, the desktop client, the iOS client, the Android client, and so on. However, a “clients” team often focuses on all of the non-web client work because so many companies have web-first products, even in our now mobile-first trend. Sometimes “platform” is used interchangeably with “client” in marketing-speak, i.e. “We are cross-platform.”

Native

Native applications are those developed for use specifically for that platform. Native iPhone apps have to be written in Objective C for example. But a hybrid app that uses webviews, or an app that is a mobile web app, can get away with using web technologies like HTML/CSS/JS that work across platforms. Early stage startups sometimes develop mobile web apps because it allows them to be cross-platform faster. But as we saw with Facebook before they went fully native, this can lead to a degraded experience because you are not “as close” to the processes of the device and have to go through the web browser instead.

Plugins

Code is often like a puzzle. If you have a puzzle and it’s missing a piece, you can’t complete the puzzle of the cute zoo animal. If you have not defined a function, but attempt to use that function in your code, it won’t work. It’s like trying to use a word in a sentence when that word does not exist - no one will understand you. Similarly, computers will not understand your code if you do not have the underlying code, the function, to make it work.

Plugins are simply extra pieces to the puzzle. Don’t want to reinvent the wheel for fancy mobile carousels? There’s a plugin for that. Don’t want to figure out grids and make buttons from scratch for your application? There’s a framework - namely Twitter Bootstrap - for that.

Related terms to “plugins” are templates, frameworks, and libraries. They are all somewhat different, but in conversation, they are sometimes used interchangeably.

Open Source

Open source can be your best and worst friend. If you are at a small startup, open source means that there is a public solution for a problem you are trying to solve. If you are a big company, this means you probably can’t use the solution because your legal department will shut you down and tell you can’t use it. In short, their argument is probably along the lines that the liability of using 3rd party intellectual property outweighs any engineering benefit you think you may get. They may be wrong, but you will lose the argument, so move on. The point is to be aware of whether the company you’re interviewing with will be receptive or not to open source solutions.

PM Question: We just built a cutting-edge framework for conversations. Now you don’t have to build your own reply/like/share functionality and design if you are building a social network or other product that has conversations. Should we open source it?

My Answer: There’s not an obvious right answer. This also isn’t often something asked of PMs, but a PM at an early stage company may weigh in on this and should at least be able to have an opinion on it. Competitively, if we open source this, it reduces the cost for a new startup trying to disrupt us. But is it really hard to build conversation structures anyway? Maybe not, and how disruptive could they be if they just copy our conversation structure? This positions as ‘experts’ of sorts since we took our solution and made a standard of sorts. Again, this isn’t really something that is asked of PMs, but the ability to think through tradeoffs in a technical and business frame is indeed important.

APIs

Application programming interface. To me, APIs are just a way for systems to talk to each other. Want your app to use Yammer’s user data? Use our secure API, so you can enhance your app the posts that your users have already made in Yammer — provided your users supply the necessary user authentication credentials. Want to post to people’s Facebook walls when they complete a run with your fitness app? You need to talk to the Facebook system, check that user’s login credentials, and then pipe your content through Facebook’s pipes. Here’s some more info on APIs.

PM Question: We want to build a product that shows people where in their neighborhoods they can purchase certain items. Can we do this with APIs and if so, which should we use?

My Answer: Yes, this can be built on top of existing APIs. For location, you probably want to use the Google Maps API. You could also consider the Foursquare API or the Locu API, which are primarily focused on information about local businesses. For purchasing items, think creatively. Which marketplaces exist? Craigslist. Well, they don’t have an official API. Presumably their data is their most valuable asset, and exporting it elsewhere would diminish visits to Craigslist.com and their advertising revenue. When a site doesn’t have an official API, people resort to web scraping, but this isn’t usually legal or acceptable. No wonder apps built on top of Craiglist often get shut down.

But back to the question - marketplaces. Milo.com - they help people find products locally and have a basic API. Or eBay’s API. But a question will be whether these APIs have geography info. Without it, you won’t have coordinates, zip codes, or anything else to pass to the Google Maps API to put pins where products are. Google Maps can draw pins on locations when provided with the info for that location and what the hovercard should contain for it. But it probably cannot supply a latitude/longitude if you feed it, say, an eBay username. That’s not what it is for. These are the sort of questions that a PM who understands APIs can reason through on a basic level.

Other Vocab

Tech Stack - all of the technologies that power your product. Imagine an actual stack with layers

Velocity - not dissimilar from the generic term, velocity is about engineering moving quickly to ship new code, features, etc.

Agile - related to velocity. Shipping small features quickly.

Summing Up

Product Managers often have varying technical abilities, especially at different companies. Google PMs tend to be more technical than say, Facebook PMs. But product management is like being the quarterback in American football. But how can a good quarterback appreciate how little time he has to throw the ball if she has never been on the frontlines to block for the quarterback? How can she understand how important a good spiral is if she has never had to catch a poorly thrown ball?

Understanding the challenges of your teammates is key to being a good leader, and hopefully these tips will help you work with your team.

Additional Resources

Programming for Non-Programmers (Chris Castiglione @ GA)

10 Tech Concepts Everyone Should Know (Benjy Weinberger @ Foursquare)

CS for Managers (David Lifson)

Flat Iron School Pre-Work (h/t Melissa Tsang for the find; authors for the content)

$20 coffee

Sat, 11 May 2013 18:48:00 -0400

$3 coffee makes little obvious economic sense. $20 makes even less. But people pay for experiences, and your product should factor in what people are really buying. Companies often charge for value that they may not even provide, but rather, value that they facilitate access to.

Take this coffee shop (on the right, behind the tree) in Hayes Valley, San Francisco. To the left are sun-soaked chairs and benches where people hang out.

The uncreative, cost-based pricing model charges for coffee beans, cups, lids, sleeves, real estate, and labor. The value-based pricing model charges for sunlight, time with loved ones, a pleasant memory, and whatever other intangibles you may enjoy over that cup o’ joe.

I don’t know if anyone would pay $20 for the same coffee that today they pay $3 for. But since we’re already paying for the experience and not the materials, why not?

Resources for Product Managers

Wed, 08 May 2013 14:13:00 -0400

Here is a list of useful resources for prospective and current PMs. Some are for novices, some for experts. Enjoy and suggest new ones in the comment section below!

What is Product Management (The Daily Muse)

“Do you often catch yourself starting sentences with, “If I designed this product, it would be better because…?” As a product manager, you make decisions across every stage of a product’s lifecycle, from its initial planning, design, and development all the way to marketing and launch. You determine what features a product should have, what order to build them in, and when to launch them. Then, you turn your big-picture ideas into a concrete, step-by-step action plan and manage it to completion, keeping everyone involved—from designers to developers to the marketing team—on the same page and in sync.”

The Art of Product Management (Notes from Product SF 2013 written by Ian Kennedy)

“PMs need to be entrepreneurs. Faced with a limited amount of resources, you need do whatever it takes to get things done. This often means you need to think creatively. Hunter also mentioned “learning to draft ascending ecosystems” – take an objective look at the market and if there is a way for you to bundle or integrate your product into another product on the rise. By focusing on getting the YouTube icon added to the default iPhone deck, all other conversations with carriers turned from YouTube chasing them to the carriers calling YouTube. Picking the ascending leader early was a bet that paid off.”

What I Look for in a Product Manager (Dave Lifson)

Lots of people have asked me how I define the role of a product manager, and, since there is so much variation, I thought I’d share my thoughts. Every company is different, but for companies that are similar to Amazon’s “2 pizza team” concept (1 tech/biz manager + 1 PM + 1 designer + 2-8 engineers operating independently of other teams in the pursuit of a particular goal), this should work.

How to Hire a Product Manager, Ken Norton

Product management may be the one job that the organization would get along fine without (at least for a good while). Without engineers, nothing would get built. Without sales people, nothing is sold. Without designers, the product looks like crap. But in a world without PMs, everyone simply fills in the gap and goes on with their lives. It’s important to remember that - as a PM, you’re expendable. Now, in the long run great product management usually makes the difference between winning and losing, but you have to prove it. Product management also combines elements of lots of other specialties - engineering, design, marketing, sales, business development. Product management is a weird discipline full of oddballs and rejects that never quite fit in anywhere else. For my part, I loved the technical challenges of engineering but despised the coding. I liked solving problems, but I hated having other people tell me what to do. I wanted to be a part of the strategic decisions, I wanted to own the product. Marketing appealed to my creativity, but I knew I’d dislike being too far away from the technology. Engineers respected me, but knew my heart was elsewhere and generally thought I was too “marketing-ish.” People like me naturally gravitate to product management.

What Distinguishes the Top 1% of Product Managers from the Top 10%?

The top 10% of product managers excel at a few of these things. The top 1% excel at most or all of them:

Think big - A 1% PM’s thinking won’t be constrained by the resources available to them today or today’s market environment. They’ll describe large disruptive opportunities, and develop concrete plans for how to take advantage of them.
Communicate - A 1% PM can make a case that is impossible to refute or ignore. They’ll use data appropriately, when available, but they’ll also tap into other biases, beliefs, and triggers that can convince the powers that be to part with headcount, money, or other resources and then get out of the way.
Simplify - A 1% PM knows how to get 80% of the value out of any feature or project with 20% of the effort. They do so repeatedly, launching more and achieving compounding effects for the product or business.

Prioritize - A 1% PM knows how to sequence projects. They balance quick wins vs. platform investments appropriately. They balance offense and defense projects appropriately. Offense projects are ones that grow the business. Defense projects are ones that protect and remove drag on the business (operations, reducing technical debt, fixing bugs, etc.).

[and more…]

Why Did Infinite Scroll Fail at Etsy? (added 5/9/13)

A tale of building a feature beyond MVP and the consequences. Original talk here.

4 Ways to Break into Product Management

The Tax of New

—

This will be a living list that I’ll update from time to time. Any suggestions on resources to add or comments on these?

A Collection of Favorite Links

Tue, 30 Apr 2013 22:12:54 -0400

This will (hopefully) grow to be a full, useful list:

How to Influence People and Win Them Over http://www.4hb.com/08iceinfuencepeople.html

Why I'm Excited about The Gov Lab

Tue, 30 Apr 2013 17:39:00 -0400

Earlier this month, I attended The Gov Lab Experiment. Led by co-founders Beth Noveck, Manik Suri, Aaron Cohen, Director of Research Stefaan Verhulst, and an army of changemakers in New York, The Governance Lab at NYU “designs more open, effective and networked institutions to improve the quality of people’s lives”.

This event brought together 100+ leaders from government and technology. We had 6 sessions focused on problem areas like “Identifying Experts” and “Asking the Right Question”. These 6 sessions of ~20 people eventually each broke into smaller teams to actually envision and build solutions to the problems that government folks were raising. By 4pm on day one of two, most teams were prototyping, and by the next morning, many teams had hacked together either a series of mockups or functioning products. Some of them were:

CareShare - choose what kind of medical specialist you need and CareShare will tell you what’s near and how well each hospital performs. It will also let you review individual doctors.

City Mission provides tools for people to ask questions about the city and collect data together.

ReallyVote lets you easily communicate thoughts with elected representatives by giving people quick access to the right congressional Twitter accounts.

Govrn allows local, state and federal governments to directly engage and question their constituents in real time.

Here are three surprising ideas I learned from my time during The Gov Lab Experiment:

Pairing up influential government leaders with competent technologists gets products built, and actually used. One without the other is often an incomplete equation for problems that need government participation for resolution.

It seemed like government folks leaned towards forming committees instead of building prototypes, and technologists wanted to hack away immediately, often missing nuances of the core issues.

But just as technical and business co-founders complement each other in technology startups, the complementary value of government leaders and technologists is undeniable. Pairing government folks, who have countless vivid use cases to share and powerful (virtually monopolistic) distribution channels, with technologists who can ship code overnight that a government committee might otherwise discuss for three years, is a potent combination and a leap forward in how we solve civic issues. It is one of the most meaningful examples of interdisciplinary partnership. We began to see this force at work as jargon-driven sessions faded away into the breakout sessions and people finally got to translating conversation into code.

If we can increase the communication between people setting policies and people building products, and make it easier for developers to access government distribution channels to promote good, perhaps private, technology solutions, the better off we will be in my view.

Technology and data need to be used to refine solutions that academics / government leaders are aiming to craft with inquiry devoid of actual user behavior.

One session I joined spent hours of just a two day conference attempting to refine an admittedly complex problem.

Participants debated what was most important for the session’s protagonist: Finding subject matter experts? Knowing which is the right expert for your specific problem? Reconciling what the various experts say? Identifying operators who can execute on whatever decision the experts propose? Building consensus around whichever decision your government makes?

Indeed, these are important questions to answer. But at data-driven technology startups, we answer questions differently: not through inquiry, but through experimentation. It’s not by asking the user what they want or what they think their problem is. It’s through data that we become enlightened. We realize that our understanding of problems, and the solutions we imagine, are rarely correct straight out of the gate. That’s why building three-year cycles or longer would spell death in a competitive market. We build a “minimum viable product” and monitor data about how people use the service to determine whether it was a good solution and what to build next. Users don’t know what they need. But the data about how people use a product will tell you whether you’re solving a problem, and in the right way or not.

Perhaps in government you only get a couple shots to get it right, and the risks are often higher, so this experimentation-oriented methodology may seem poorly suited. But people said the same in the software industry, and that mentality collapsed. I believe an experiment-over-inquiry methodology will be the future across industries and governance.

One could spend all day talking back and forth about what *might* be the core problem and what the user *thinks* the solution should look like. We cannot allow anyone — the government leaders who aren’t technologists, or technologists who are not government folks — to overrule data in shaping the product’s development.

For example, before 311 emerged, one could debate whether anyone would use it. Which government programs it should plug into. Whether making complaints was more important functionality than filing for licenses. Sure, you could convene a committee to prioritize, or you could survey all the citizens for a few months. But you could also just hack an MVP (“minimum viable product”), measure what people use, and build new features based on the behaviors that people actually demonstrate.

This is the Ivy Tower problem, now met with a Silicon Valley attitude.

Getting more people, especially developers, simply to be aware, and invested in, improving governance is a still-untapped source of innovation.

Since walking away from The Gov Lab Experiment last week, I have talked to dozens of people about the role of tech in improving governance and more. I have started hacking on a new civic tech project for fun. I have a hard time hearing about some new legislation or civic problem without thinking about products that may be the answer. I was barely interested in civic tech before.

To be clear, not every problem is a technology problem. Not everything can, or should, be productized.

But from my experience, developers and startups can disrupt most any industry they set their eyes on. Napster, and now Pandora/Spotify are doing it to music. Paypal, and now Square/Stripe, are doing it to payments. The web, and specifically Facebook/Twitter, are doing it to the media industry along with an array of other industries all at once. Yet developers appear to have been relatively quiet in government.

It’s not because government is hard to disrupt: every industry is hard to disrupt.

It’s not because it’s not lucrative: government contracts and getting a whole city or country to use an application would be more lucrative than a lot of other markets.

It’s not because hacking government isn’t appealing: developers love making impact.

So, simply getting and keeping developers engaged in civic tech is limitlessly powerful.

—

That’s why events like The Gov Lab Experiment and others like it are so important. Just promoting the governance idea to people who are actively building solutions that would otherwise be in other industries and spaces will keep it top of mind. So when these technologists interact with governance bodies and civic systems on a daily basis, building solutions will feel more in reach and are more likely to materialize as opposed to another social networking app. Moreover, supporting people from the two disciplines to coordinate better and learn from each other’s methodologies can only accelerate the rate of change in civic tech.

(If you would like to get involved with The Gov Lab or hack with me on some gov 2.0 projects, let me know).

Unlearning: Signaling Completion for the Sake of Validation

Wed, 24 Apr 2013 16:19:18 -0400

During my education and social experiences (i.e. my life thus far), I have developed a behavior I would like to unlearn: signaling completion for the sake of validation.

This morning, a friend shared a post with me. He knew I would upvote it on Hacker News. There was literally no need for me to signal that I had in fact upvoted it. But, I am used to telling people that I have done something even when they will know that I did anyway when the result reaches them or because we had an understanding beforehand.

Another example is when I introduce people. Both people will get the introduction email. Yet, I still often go back to the email thread that requested the intro, and let the original person know. Sure, sometimes there’s other stuff in that email, or it’s a nudge for the junior person to follow up with the senior person. Or it’s just a courtesy. But often it’s not. I just want them to say thanks, again, or somehow acknowledge what’s been done. Or a pat on the back saying, “Good job ol’ boy”.

It’s a silly habit. It generally is a waste of time, but people who did well in school or who enjoyed the rewards of school, seek validation out in many forms…

Promotions with no change in role or compensation - just title.

Media coverage that doesn’t do anything meaningful for the business.

And so on.

Eliminating this behavior (pointless calls for validation) saves time and will wean one off of external validation, which is often a red herring that distracts from meaningful progress.

(I am not sure if I agree with, or have baked, everything I’m even saying here, but maybe it will be a launching point for a productive conversation, or not. Let me know if you disagree.).

Blogging Takes Persistence. My first 13 posts got 4 or less...

Thu, 11 Apr 2013 18:16:20 -0400

Blogging Takes Persistence. My first 13 posts got 4 or less upvotes, never making the front page. It’s a year later. Today’s post on Foursquare has gotten 50 upvotes and more than 3,000 page views so far today.

Foursquare: An Ads Business With a Dying Product Hook

Thu, 11 Apr 2013 11:36:00 -0400

Foursquare just announced an additional $41m in funding. Many believe this to be the company’s last major chance to show it can build a large business on the back of a successful consumer app with some inroads into SMBs and large brands alike.

Let me begin by saying, I am not trying to be a troll or hater. Promise. I want this to be a constructive conversation. With so many people building consumer apps, and often delaying “the revenue conversation”, understanding the connection between building (and sustaining, if not growing) a product hook and growing revenue needs to be fleshed out.

I want to be excited for them. But from a purely critical standpoint, I have a hard time seeing them pull this off. They are building a business that is orthogonal to what I believe is the core user behavior. That’s dangerous.

Emphasis on Friends and Check-Ins: Ditched for Promoting Local Businesses…a fatal attempt at making an app into a business

This is actually a huge product pivot. People came to Foursquare before for different reasons than *discovering* new businesses. Checkins. Meet people. But now…the focus is on pushing me to go to a local pastry shop to save 50%, max $5 — on something I didn’t want before? By contrast, Yelp has always been focused on the best — if it’s 5 stars and you say you want something close, you’ll see the best possible matches even if those results are preceded by a promoted restaurant (same way Google does it).

But now Foursquare is an ads business. When I say “ads”, I mean local promotions and beyond. They are already doing this (see the above screenshot). So, there’s not really a debate IMO about whether they are an ads business today. Maybe they can have multiple revenue streams in the way that Linkedin has done, but arguing about whether Foursquare is an advertising company, at least right now, is a red herring that distracts from the core argument here.

Generating and Harvesting Purchasing Intent Will Not Work without a Core Product Hook

Google Ads work because they just harvest intent. “You want (you search for) something? OK here are some businesses that can sell you that.” That’s relatively easy and gives the users what they wanted in the first place. Typing a search is an easy hook and has been increasingly adopted over time. Now that behavior is ubiquitous. It has evolved (search from browser address bars, speak-to-search, etc.) but remained easy, engaging, and ubiquitous.

Another easy product hook is posting an update on Facebook or Twitter: lightweight and it has opportunities to create engagement loops when people Like, reply to, retweet, share, or do anything else with your content.

The key problem here is the Foursquare is attempting to generate AND harvest demand without a product hook (checkins have been taken away by competitors building better, focused experiences). No one wanted a pastry. I sure didn’t. Pastries are irrelevant to me right now and most times. But this is the new product emphasis built on top of a product hook (check-ins) with evaporating utility in the Foursquare ecosystem. Check-ins are moving to Facebook, Path, etc., so now Foursquare is left with local promotions but no core utility for the user.

Facebook can get away with generating and harvesting intent for a few reasons that don’t work for Foursquare.

1. (Un)targeted demand generation: Facebook can target who it generates intent for. Showing pastries to me is irrelevant. But showing me ads for analytics services, ridesharing apps, and more…is not. Advertisers can be very targeted on Facebook. Foursquare - with just basic information about me - can’t do the same frighteningly good job of targeting who they target in order to generate demand. Untargeted demand generation is resource intensive and converts poorly. In a world of hyper-targeting, Foursquare’s geodata and basic demographics are close to “untargeted”.

2. Scale: Even if Facebook ads convert poorly, the sheer number of users and amount of engagement they register with the product (pageviews on Facebook vs. loads of the Foursquare app are different orders of magnitude) gives Facebook more opportunities to generate and harvest intent such that it can compensate for the low CTR that people complain about.

3. Fulfillment Friction: Foursquare is an example of an online solution powering offline commerce. That’s bold, so I respect it. But even if I am walking around my neighborhood, if I go to the pastry place Foursquare recommends, I have to a) walk there, even if it’s close b) convince whomever I am with to go with me. On the other hand, Facebook just needs me to either load a page (frictionless, since I am doing that anyway to enjoy their core product) or make one click — depending on if an advertiser is running a CPM or CPC campaign. Foursquare fulfillment of promotions is very difficult to drive conversions for. I am sure there is a big drop off between the offers viewed and those redeemed.

Therefore, there is a clear misalignment between the value that Foursquare aims to deliver and what their users want. It’s like intentionally foregoing product market fit in an attempt to squeeze some revenue out of a minority of users. I don’t blame them because they were already seeing corroding product-market fit with a check-in product in a world in which check-ins alone don’t suffice due to changing consumer behavior. That’s not to mention increasing competition through Facebook, Path, and Highlight-type of apps — each with a different spin on check-ins that took away chunks of Foursquare users better served by those individual apps.

I hope Foursquare proves me wrong. They are pirates, in the game, trying to make something big happen. I respect that, and don’t want to “be a hater”. I used to be a user of their app. I have no doubt they can have a large exit even if they don’t pull this move off. But I don’t see them building a large independent business when their core product hook is both corroding and orthogonal to how they generate revenue — and that should be a lesson to others building large consumer apps that aim to be large consumer or B2C2B businesses one day.

—

This has picked up on Hacker News. Discuss here https://news.ycombinator.com/item?id=5532680. Also Jason Baptiste makes some good counterpoints in a separate post made today.

Why Dropdown Menus Save People Time

Thu, 11 Apr 2013 00:20:00 -0400

Elements like rounded buttons and menus with expandable content have made it into web apps everywhere. New design elements and interactions tend to spread fast. But over time, no one really questions why they are the way they are. Similarly, people don’t appreciate the value they deliver and remember how the interaction was before. This hinders our ability to rethink interfaces and advance user experiences at a faster pace.

As an analogy, people also forget that suitcases didn’t always have wheels on them. Not until 1970.

Isn’t this so much better:

While I’m not a fan of most of PayPal’s design, I’ll give them an easy layup on good UX here by appreciating their use of a dropdown menu.

Unable to display content. Adobe Flash is required.

Use Case: Person would like to withdraw money from PayPal.

UX Problem: There are at least 3 sources for that withdrawal to be deposited into: 1. Bank Account 2. Check 3. PayPal Debit Card. This affects the user flow. But loading a brand new page just to select which of these choices a person wants increases friction: new page load, changes view, takes time, disorients a user, etc.

(Side note: It also requires designing, building, and maintaining a whole new page. This is bad for the user experience and expensive for the design/engineering teams.)

UX Solution: Allow a user to semi-actively indicate the need to withdraw money without clicking and changing the view. Hover is lighter than a click. Then show the options in place and the user can choose one with a click. Avoid the page change. Have this occur without the options disappearing when the user mouses away from the original target into the drop-down options since they are likely to mouse down into the options.

—

These dropdowns are everywhere today and well covered (Smashing Magazine post), but it’s nice to appreciate the fundamental problem they solve. It also helps us brainstorm newer solutions. For example, maybe one day you won’t even click on the dropdown options but rather hover over those, too. This would reduce the cost of the physical action needed to express intent (hovers are lighter than clicks). Of course, the chances of mis-hovers goes up with a solution like this, but it’s a single example as a thought exercise.

Svbtle uses this interaction well (hovers for action), and since the element is not a drop-down, there’s no risk of mis-hovers.

Unable to display content. Adobe Flash is required.

Or maybe in the future you can enter the amount to withdraw / submit the request from the dropdown and *never* change views. Maybe the whole website becomes just a webpage.

Anyway…next time you use a drop-down menu, hopefully you remember how much time and hassle it saves. And maybe you can invent the next UX interaction that will make everyone’s lives better.

Content Providers Need to Rethink Branding for Mobile UX

Wed, 10 Apr 2013 23:15:00 -0400

Recently I was reading an article in The Economist on my phone. Articles are increasingly consumed within in-app web browsers. It’s important for media outlets to brand themselves well in this new medium.

As I scrolled, as readers tend to do through articles, I couldn’t help but notice the bright red, sticky logo of The Economist.

Later, when I wanted to mention this article, you can be sure that I knew where I had read it: The Economist.

Sticky headers. Noticeable logos. It matters. Especially in a world of undifferentiated forms of media consumptions (link shorteners often obscure your brand, articles are read as one-offs through social media vs. in your magazine next to all of your other articles, etc.)

Contrast how The Economist does this to how, of all sources, a technology blog: Pandodaily.

Had Twitter’s web browser not displayed the URL at the top of the page, you wouldn’t even be able to *figure out* that Pandodaily was the source, let alone have an easy brand association form naturally.

Content providers that don’t implement various branding tactics for the new mobile world - like sticky headers - are missing out on important opportunities to associate themselves with otherwise memorable moments.

Get Kicked Often

Mon, 01 Apr 2013 22:48:41 -0400

Panting, with salt-filled sweat barely escaping my eyes, I sat down to write this post. This post is about how failure motivates me and why it’s necessary to let yourself be kicked often in order to stay fired up.

—

I just returned from my first game of full court basketball in as long as I can remember. I scored 0 points. Fear not, I had my shots — 4 layups and 2 jumpers. 4 pretty open layups, mind you. I missed them all. All.

Originally, I declined the offer to play in the game preferring the comfort of making my own free throws and layups on my half of the court. I feared embarrassment in front of peers. But I played, and failed. Quite well, really.

While I returned from the court annoyed with myself on one hand for missing all of my shorts, I was also fired up and motivated. Why, I wondered.

Failure for me, like for many others, is more of a motivator than a deterrent. Many people, especially entrepreneurs, use rejection, obstacles, etc. as reasons to push through. Indeed, I have felt this much longer than I have known what a “startup” is.

My reasons for starting my first company had a lot more to do with proving people wrong than it did anything about a real cause or the proclaimed glory of running a business. My family had moved from New Jersey to Florida, I had very few if any friends in my new school, and if I couldn’t be popular, I wanted to be successful. The business eventually took off, and oddly enough, that made me more popular at school.

Yet, as people achieve forms of success, there are less people telling you you’re wrong. So, if you’re someone who uses rejection as motivation and that motivation begets success, it becomes easier to become complacent as you do better and better in life. I suspect this is why people who do what they do for more core reasons, such as a strong belief in righting an injustice they feel personally, can carry on fervently without many other stimuli and surpass others “in it for the wrong reasons.”

But if you are like me, and failure and/or people scoffing lights a fire for you, it’s imperative to remember to frequently rekindle sources of motivation. This is relevant to the conversation about pushing yourself outside of one’s comfort zone. But to me, this particular piece is more nuanced than that cliché advice. And like other ‘advice’, it means nothing if it is just read but not practiced.

Being kicked in the gut motivates me. With things going well, I forgot what it was like to be kicked. If you are like me, don’t forget to get kicked often if you want to reach more than the tip of the iceberg.

The Credentials Trap Within Startups

Sat, 30 Mar 2013 14:58:00 -0400

Effectively navigating the startup world requires good judgment of people.

If you are an investor, knowing the common qualities of successful founders is helpful. As a founder, being able to make good hires early on helps a lot. And so on.

One way people broadcast that they will be a good investor, hire, etc. is through their credentials.

But for the people looking to build out their credentials, Chris Dixon rightfully cautioned people against the credentials trap recently, and Justin Kan declared your credentials worthless. I really value how Chris and Justin discourage seeking out external validation in favor of seeking genuine learning and creating real value.

In other industries, saying you’re a Harvard MBA who was the president of the Tech & Media Club and a Baker Scholar means a lot. You may have never *built* anything, yet you can make a strong, positive impression on whomever is hiring you.

Tech is a little different. To a large degree, people care more about *what you can actually do*. This may be because in tech you more often have to do the unknown. In other jobs in other industries, you may just have to execute a known process - which is a very different skill set. Going from 0 to 1 in an intensive process - one that is starkly different than going from 1 to n, as Peter Thiel articulated.

Yet, judging what a person or firm is capable of remains challenging. So people fall back on signaling as they often do.

Credentialing in the startup world is now about which companies you have been involved with, and at what stage. For investors, it’s listing their portfolio companies logos. For employees, it’s a Linkedin profile filled with one acquisition after another, maybe with an IPO thrown in there.

Smart people wondering whether to work with you will still be able to figure out your actual involvement. Yes, there is still value in being associated with successful companies. All else equal, you appear better than someone else.

Dixon talked about the trap largely in the context of going to a startup vs. established companies. Maybe he meant Dropbox, but to me established meant Google. And I think there’s a trap to joining a Dropbox as well.

As tech continues to pick up steam and there are seemingly more “hits”, it seems to have become easier to be associated with the homeruns but never build one yourself. Today you could go join Dropbox, or Square, or Box, or Uber, or even Stripe. Companies of varying revenue, headcount, guarantees of success. But in my eyes, none of these companies will fail. They’re all brand names in the tech startup world with real revenue.

But, honestly, join today and there’s very little chance you will be the reason these companies succeeded. Yet you and your Linkedin profile will benefit from the brand name and eventually the halo effect.

When I joined Yammer, it was clear that the company was a homerun. They just raised a massive round from top tier investors. They were a household name in the startup world. I didn’t cause the success that resulted in Microsoft buying Yammer a few months after I joined. Far from it. Yet people still associate me with Yammer’s success just because I was part of the company before the acquisition.

Anyway, the point here is that there is a credentialing trap even within startups, not just between startups and Google. This is even more true as big companies lose their luster to hot startups. Indeed, the trap just shifts then to where there is the most prestige. Maybe it already has shifted toward hot startups, at least in some circles. Your parents may still want you to work at Microsoft and provide external validation if you work there. But your friends may admire you more for being the 100th hire at the next pre IPO company. And if you are after external validation, your friends can be a source of that, too. Perhaps an even stronger source.

But should you join Square as employee #500 or the no-name startup that you really believe in but know will probably fail as employee #10?

I don’t know. But as I think about what comes after Yammer, it’s very tempting to take another role at another sure-to-succeed company. Yammer + [Successful Company]. Would be 2 great companies to be associated with and resemble a “track record”. Do something earlier stage and it will probably fail, and perhaps that’s perceived “as a step down”. Yet as I think about what comes next, being keenly aware of the credentials trap has been very helpful to keep things in perspective.

My thoughts on 'Stuff'

Thu, 14 Mar 2013 00:17:00 -0400

This is going to be my first non-UX post in a while. Back to some personal stuff with this one.

This week there’s a lot of talk about “Living with Less”, perhaps kicked off by the NYT piece: http://www.nytimes.com/2013/03/10/opinion/sunday/living-with-less-a-lot-less.html?pagewanted=1&_r=1&.

http://vruba.tumblr.com/post/45256059128/wealth-risk-and-stuff

http://www.paulgraham.com/stuff.html (resurfaced; originally published in 2007).

So, I did a thought exercise. Looked around my apartment. Thought about things I could cut out…

1) Couches (use the chairs from the dining table when needed)

2) Don’t have a TV, but that would be next

3) Miscellanea: Flower pots, candles, photo frames, random art, nerf guns, etc. To be far, this stuff is largely personal and helps my place feel more like home. But, it is stuff.

4) Fitness: Dumbbells, bench, chin up bar. I suppose if I went to the gym, I wouldn’t need to have this at home.

5) Wine racks / wine / other alcohol - I could just get what I need when I need it.

6) Bedding for when people visit

7) Other stuff

Fortunately, living in San Francisco virtually dictates that I live in a small apartment. So there’s not a lot of space to begin with. I moved a desk into storage along with some other stuff.

So, where did this thinking lead me? I have a decent amount of ‘stuff’. But a lot of this stuff is also what makes me feel at home.

The next logical question, “Is that habit or the way things have to be?” In other words, am I just used to having a lot of stuff? Maybe I’d feel at home in a place with less stuff once I gave it time.

Curious if anyone else who’s not writing some major article about this topic has some experience with experimenting with the space and stuff around them.